Getting Started with QNX Neutrino - QNX Software Systems

© 2009, QNX Software Systems GmbH & Co. KG. Using message passing
Not replying to the client
Replying with no data, or an errno
There’s absolutely no requirement that you reply to a client before accepting new
messages from other clients via MsgReceive()! This can be used in a number of
different scenarios.
In a typical device driver, a client may make a request that won’t be serviced for a long
time. For example, the client may ask an Analog-to-Digital Converter (ADC) device
driver to “Go out and collect 45 seconds worth of samples.” In the meantime, the ADC
driver shouldn’t just close up shop for 45 seconds! Other clients might wish to have
requests serviced (for example, there might be multiple analog channels, or there
might be status information that should be available immediately, etc.).
Architecturally, the ADC driver will simply queue the receive ID that it got from the
MsgReceive(), start up the 45-second accumulation process, and go off and handle
other requests. When the 45 seconds are up and the samples have been accumulated,
the ADC driver can find the receive ID associated with the request and then reply to
the client.
You’d also want to hold off replying to a client in the case of the reply-driven
server/subserver model (where some of the “clients” are the subservers). Since the
subservers are looking for work, you’d simply make a note of their receive IDs and
store those away. When actual work arrived, then and only then would you reply to the
subserver, thus indicating that it should do some work.
When you finally reply to the client, there’s no requirement that you transfer any data.
This is used in two scenarios.
You may choose to reply with no data if the sole purpose of the reply is to unblock the
client. Let’s say the client just wants to be blocked until some particular event occurs,
but it doesn’t need to know which event. In this case, no data is required by the
MsgReply() function; the receive ID is sufficient:
MsgReply (rcvid, EOK, NULL, 0);
This unblocks the client (but doesn’t return any data) and returns the EOK “success”
indication.
As a slight modification of that, you may wish to return an error status to the client. In
this case, you can’t do that with MsgReply(), but instead must use MsgError():
MsgError (rcvid, EROFS);
In the above example, the server detects that the client is attempting to write to a
read-only filesystem, and, instead of returning any actual data, simply returns an errno
of EROFS back to the client.
Alternatively (and we’ll look at the calls shortly), you may have already transferred
the data (via MsgWrite()), and there’s no additional data to transfer.
Why the two calls? They’re subtly different. While both MsgError() and MsgReply()
will unblock the client, MsgError() will not transfer any additional data, will cause the
April 30, 2009 Chapter 2 • Message Passing 101