Getting Started with QNX Neutrino - QNX Software Systems

© 2009, QNX Software Systems GmbH & Co. KG. Pulses
_NTO_CHF_SENDER_LEN
The kernel delivers the client’s message size as part of the information given to
the server (the srcmsglen member of the struct _msg_info structure).
_NTO_CHF_REPLY_LEN
The kernel delivers the client’s reply message buffer size as part of the
information given to the server (the dstmsglen member of the struct
_msg_info structure).
_NTO_CHF_COID_DISCONNECT
The kernel delivers a pulse whenever any connection owned by this process is
terminated due to the channel on the other end going away.
_NTO_CHF_UNBLOCK
Let’s look at the _NTO_CHF_UNBLOCK flag; it has a few interesting wrinkles for
both the client and the server.
Normally (i.e., where the server does not specify the _NTO_CHF_UNBLOCK flag)
when a client wishes to unblock from a MsgSend() (and related MsgSendv(),
MsgSendvs(), etc. family of functions), the client simply unblocks. The client could
wish to unblock due to receiving a signal or a kernel timeout (see the TimerTimeout()
function in the Neutrino Library Reference, and the Clocks, Timers, and Getting a
Kick Every So Often chapter). The unfortunate aspect to this is that the server has no
idea that the client has unblocked and is no longer waiting for a reply. Note that it isn’t
possible to write a reliable server with this flag off, except in very special situations
which require cooperation between the server and all its clients.
Let’s assume that you have a server with multiple threads, all blocked on the server’s
MsgReceive() function. The client sends a message to the server, and one of the
server’s threads receives it. At this point, the client is blocked, and a thread in the
server is actively processing the request. Now, before the server thread has a chance to
reply to the client, the client unblocks from the MsgSend() (let’s assume it was because
of a signal).
Remember, a server thread is still processing the request on behalf of the client. But
since the client is now unblocked (the client’s MsgSend() would have returned with
EINTR), the client is free to send another request to the server. Thanks to the
architecture of Neutrino servers, another thread would receive another message from
the client, with the exact same receive ID! The server has no way to tell these two
requests apart! When the first thread completes and replies to the client, it’s really
replying to the second message that the client sent, not the first message (as the thread
actually believes that it’s doing). So, the server’s first thread replies to the client’s
second message.
This is bad enough; but let’s take this one step further. Now the server’s second thread
completes the request and tries to reply to the client. But since the server’s first thread
already replied to the client, the client is now unblocked and the server’s second thread
gets an error from its reply.
April 30, 2009 Chapter 2 • Message Passing 119