Getting Started with QNX Neutrino - QNX Software Systems

© 2009, QNX Software Systems GmbH & Co. KG. Using message passing
obvious method of cleaning up these files, except perhaps to have a “grim reaper” task
that runs around seeing if these things are still valid.
There’s another related problem. Since the process that created the file can die without
removing the file, there’s no way of knowing whether or not the process is still alive
until you try to send a message to it. Worse yet, the ND/PID/CHID specified in the file
may be so stale that it would have been reused by another program! The message that
you send to that program will at best be rejected, and at worst may cause damage. So
that approach is out.
The second approach, where we use global variables to advertise the ND/PID/CHID
values, is not a general solution, as it relies on the client’s being able to access the
global variables. And since this requires shared memory, it certainly won’t work
across a network! This generally gets used in either tiny test case programs or in very
special cases, but always in the context of a multithreaded program. Effectively, all
that happens is that one thread in the program is the client, and another thread is the
server. The server thread creates the channel and then places the channel ID into a
global variable (the node ID and process ID are the same for all threads in the process,
so they don’t need to be advertised.) The client thread then picks up the global channel
ID and performs the ConnectAttach() to it.
The third approach, where we use the name_attach() and name_detach() functions,
works well for simple client/server situations.
The last approach, where the server becomes a resource manager, is definitely the
cleanest and is the recommended general-purpose solution. The mechanics of “how”
will become clear in the Resource Managers chapter, but for now, all you need to
know is that the server registers a particular pathname as its “domain of authority,” and
a client performs a simple open() of that pathname.
What about priorities?
I can’t emphasize this enough:
POSIX file descriptors are implemented using connection IDs; that is, a file descriptor
is a connection ID! The beauty of this scheme is that since the file descriptor that’s
returned from the open() is the connection ID, no further work is required on the
client’s end to be able to use that particular connection. For example, when the client
calls read() later, passing it the file descriptor, this translates with very little overhead
into a MsgSend() function.
What if a low-priority process and a high-priority process send a message to a server
at the same time?
April 30, 2009 Chapter 2 • Message Passing 103