Getting Started with QNX Neutrino - QNX Software Systems

Using message passing
© 2009, QNX Software Systems GmbH & Co. KG.
More about channels
Who sent the message?
In the server example above, we saw that the server created just one channel. It could
certainly have created more, but generally, servers don’t do that. (The most obvious
example of a server with two channels is the Transparent Distributed Processing (TDP,
also known as Qnet) native network manager — definitely an “odd” piece of
software!)
As it turns out, there really isn’t much need to create multiple channels in the real
world. The main purpose of a channel is to give the server a well-defined place to
“listen” for messages, and to give the clients a well-defined place to send their
messages (via a connection). About the only time that you’d have multiple channels in
a server is if the server wanted to provide either different services, or different classes
of services, depending on which channel the message arrived on. The second channel
could be used, for example, as a place to drop wake up pulses — this ensures that
they’re treated as a different “class” of service than messages arriving on the first
channel.
In a previous paragraph I had said that you could have a pool of threads running in a
server, ready to accept messages from clients, and that it didn’t really matter which
thread got the request. This is another aspect of the channel abstraction. Under
previous versions of the QNX family of operating systems (notably QNX 4), a client
would target messages at a server identified by a node ID and process ID. Since QNX
4 is single-threaded, this means that there cannot be confusion about “to whom” the
message is being sent. However, once you introduce threads into the picture, the
design decision had to be made as to how you would address the threads (really, the
“service providers”). Since threads are ephemeral, it really didn’t make sense to have
the client connect to a particular node ID, process ID, and thread ID. Also, what if that
particular thread was busy? We’d have to provide some method to allow a client to
select a “non-busy thread within a defined pool of service-providing threads.”
Well, that’s exactly what a channel is. It’s the “address” of a “pool of
service-providing threads.” The implication here is that a bunch of threads can issue a
MsgReceive() function call on a particular channel, and block, with only one thread
getting a message at a time.
Often a server will need to know who sent it a message. There are a number of reasons
for this:
• accounting
• access control
• context association
• class of service
• etc.
98 Chapter 2 • Message Passing April 30, 2009