More about channels
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 process with multiple channels is the filesystem drivers, devb-*).
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
has to be made as to how you would address the threads (really, the
service providers
).
Since threads are ephemeral,
it really doesn'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.