Getting Started with QNX Neutrino - QNX Software Systems

© 2009, QNX Software Systems GmbH & Co. KG. Examples
Step 7
Step 8
Step 9
Now we advance the lseek() offset by the number of bytes that we returned to the
client, only if we are not processing the _IO_XTYPE_OFFSET override modifier. This
ensures that, in the non-_IO_XTYPE_OFFSET case, if the client calls lseek() to get the
current position, or (more importantly) when the client calls read() to get the next few
bytes, the offset into the resource is set to the correct value. In the case of the
_IO_XTYPE_OFFSET override, we leave the ocb version of the offset alone.
Contrast step 6 with this step. Here we only unblock the client, we don’t perform any
other functions. Notice also that there is no data area specified to the MsgReply(),
because we’re not returning data.
Finally, in step 9, we perform processing that’s common regardless of whether or not
we returned data to the client. Since we’ve already unblocked the client via the
MsgReply(), we certainly don’t want the resource manager library doing that for us, so
we tell it that we’ve already done that by returning _RESMGR_NOREPLY.
Effective use of other messaging functions
A simple io_write() example
As you’ll recall from the Message Passing chapter, we discussed a few other
message-passing functions — namely MsgWrite(), MsgWritev(), and MsgReplyv().
The reason I’m mentioning them here again is because your io_read() function may
be in an excellent position to use these functions. In the simple example shown above,
we were returning a contiguous array of bytes from one memory location. In the real
world, you may need to return multiple pieces of data from various buffers that you’ve
allocated. A classical example of this is a ring buffer, as might be found in a serial
device driver. Part of the data may be near the end of the buffer, with the rest of it
“wrapped” to the top of the buffer. In this case, you’ll want to use a two-part IOV with
MsgReplyv() to return both parts. The first part of the IOV would contain the address
(and length) of the bottom part of the data, and the second part of the IOV would
contain the address (and length) of the top part of the data. Or, if the data is going to
arrive in pieces, you may instead choose to use MsgWrite() or MsgWritev() to place
the data into the client’s address space as it arrives and then specify a final MsgReply()
or MsgReplyv() to unblock the client. As we’ve seen above, there’s no requirement to
actually transfer data with the MsgReply() function — you can use it to simply
unblock the client.
The io_read() example was fairly simple; let’s take a look at io_write(). The major
hurdle to overcome with the io_write() is to access the data. Since the resource
manager library reads in a small portion of the message from the client, the data
content that the client sent (immediately after the _IO_WRITE header) may have only
partially arrived at the io_write() function. To illustrate this, consider the client writing
one megabyte — only the header and a few bytes of the data will get read by the
April 30, 2009 Chapter 5 • Resource Managers 259