Project Home
Project Home		 Documents
Documents		 Wiki
Wiki		 Discussion Forums
Discussions		 Project Information
Project Info
QNX Operating System/Discussion/OSTech/Using resmgr_msg_again to implement blocking read/List of Posts
Forum Topic - Using resmgr_msg_again to implement blocking read: (5 Items)
   
Update
David Baker(deleted)
10/09/2008 4:47 PM
post14794
Using resmgr_msg_again to implement blocking read   
I am writing a resource manager and am trying to implement a blocking read.  I am saving the rcvid from the original 
read request.  

I have used select_attach to wait for data from another file descriptor.  When that descriptor comes ready, my attached 
function reads the data from that file descriptor.  I would like to satisfy the original read request by using 
resmgr_msg_again and my saved rcvid, however the context structure passed in is a select_context_t instead of the 
resmgr_context_t that resmgr_msg_again requires.

The compiler doesn't like me passing in the select_context_t, which seems reasonable.  Is there any way for me to obtain
 the resmgr_context_t from the select_context_t pointer I have?  

Is there a better way to do this in general?
Thomas Fletcher
10/10/2008 9:12 AM
post14818
Re: Using resmgr_msg_again to implement blocking read   
David Baker wrote:
>  I am writing a resource manager and am trying to implement a blocking
>  read.  I am saving the rcvid from the original read request.
>
>  I have used select_attach to wait for data from another file
>  descriptor.  When that descriptor comes ready, my attached function
>  reads the data from that file descriptor.  I would like to satisfy
>  the original read request by using resmgr_msg_again and my saved
>  rcvid, however the context structure passed in is a select_context_t
>  instead of the resmgr_context_t that resmgr_msg_again requires.
>
>  The compiler doesn't like me passing in the select_context_t, which
>  seems reasonable.  Is there any way for me to obtain the
>  resmgr_context_t from the select_context_t pointer I have?
>
>  Is there a better way to do this in general?

The problem with resmgr_msg_again() is that it will 'replay' the
original message all over again, which is pretty inefficient. 

Since you are already saving the rcvid (and presumably doing any
validation required for the read request) you might be better off
saving a bit more state information yourself (ie offset and read
length) and then when you get the data in the select_attach() callback
use MsgWrite() and/or MsgReply() to send the data to the client
that called read() directly.

Hope this helps,
 Thomas
Glenn Schmottlach
10/20/2008 9:28 AM
post15228
Re: Using resmgr_msg_again to implement blocking read   
I have a question related to this thread. A resource managers read/write handlers receive the following parameters:

int ioWrite(resmgr_context_t* ctp,
               io_write_t*       msg,
               iofunc_ocb_t*  ocb)

and

int ioRead(resmgr_context_t* ctp,
               io_read_t*        msg,
               iofunc_ocb_t*  ocb)

In the situation where these read/write requests are deferred (e.g. the caller is blocked until there is data available 
to read/write and _RESMGR_NOREPLY is returned), can any of the above pointers be safely saved and subsequently 
referenced later when the request is finally handled? Ideally, I'd like to create a client structure that contained 
copies of the above pointers as the context of the call and use these parameters later to complete the request (whether 
it's a read/write). The client structures are maintained in a linked-list owned by the resource manager until the 
original request is handled. Are any of the pointers provided by the read/write handlers destroyed when the functions 
return (if they're not immediately satisfied and _RESMGR_NOREPLY is returned). What can I assume is safe to cache and 
access later?
Colin Burgess(deleted)
10/20/2008 9:48 AM
post15231
Re: Using resmgr_msg_again to implement blocking read   
The ctp and msg pointers point to the threads context, and cannot be saved (since the msg will be overwritten the next
time a thread receives a message)

You will need to allocate your own pending request structure and save the pertinent info there.

Colin

Glenn Schmottlach wrote:
> I have a question related to this thread. A resource managers read/write handlers receive the following parameters:
> 
> int ioWrite(resmgr_context_t* ctp,
>                io_write_t*       msg,
>                iofunc_ocb_t*  ocb)
> 
> and
> 
> int ioRead(resmgr_context_t* ctp,
>                io_read_t*        msg,
>                iofunc_ocb_t*  ocb)
> 
> In the situation where these read/write requests are deferred (e.g. the caller is blocked until there is data 
available to read/write and _RESMGR_NOREPLY is returned), can any of the above pointers be safely saved and subsequently
 referenced later when the request is finally handled? Ideally, I'd like to create a client structure that contained 
copies of the above pointers as the context of the call and use these parameters later to complete the request (whether 
it's a read/write). The client structures are maintained in a linked-list owned by the resource manager until the 
original request is handled. Are any of the pointers provided by the read/write handlers destroyed when the functions 
return (if they're not immediately satisfied and _RESMGR_NOREPLY is returned). What can I assume is safe to cache and 
access later?
> 
> 
> 
> 
> 
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post15228
> 

-- 
cburgess@qnx.com
Glenn Schmottlach
10/20/2008 10:33 AM
post15234
Re: Using resmgr_msg_again to implement blocking read   
To be clear, for a single-threaded resource manager, it would be kosher to cache the ocb pointer, right???

I need a reference to the ocb so I can update the "time" if it's a deferred write.

Return


  A subsidiary of BlackBerry             All content ©2004-2013, QNX Software Systems