Getting Started with QNX Neutrino - QNX Software Systems

Using message passing
© 2009, QNX Software Systems GmbH & Co. KG.
Finding the server’s ND/PID/CHID
client’s MsgSend() function to return -1, and will cause the client to have errno set to
whatever was passed as the second argument to MsgError().
On the other hand, MsgReply() could transfer data (as indicated by the third and fourth
arguments), and will cause the client’s MsgSend() function to return whatever was
passed as the second argument to MsgReply(). MsgReply() has no effect on the client’s
errno.
Generally, if you’re returning only a pass/fail indication (and no data), you’d use
MsgError(), whereas if you’re returning data, you’d use MsgReply(). Traditionally,
when you do return data, the second argument to MsgReply() will be a positive integer
indicating the number of bytes being returned.
You’ve noticed that in the ConnectAttach() function, we require a Node Descriptor
(ND), a process ID (PID), and a channel ID (CHID) in order to be able to attach to a
server. So far we haven’t talked about how the client finds this ND/PID/CHID
information.
If one process creates the other, then it’s easy — the process creation call returns with
the process ID of the newly created process. Either the creating process can pass its
own PID and CHID on the command line to the newly created process or the newly
created process can issue the getppid() function call to get the PID of its parent and
assume a “well-known” CHID.
What if we have two perfect strangers? This would be the case if, for example, a third
party created a server and an application that you wrote wanted to talk to that server.
The real issue is, “How does a server advertise its location?”
There are many ways of doing this; we’ll look at four of them, in increasing order of
programming “elegance”:
1 Open a well-known filename and store the ND/PID/CHID there. This is the
traditional approach taken by UNIX-style servers, where they open a file (for
example, /etc/httpd.pid), write their process ID there as an ASCII string,
and expect that clients will open the file and fetch the process ID.
2 Use global variables to advertise the ND/PID/CHID information. This is
typically used in multi-threaded servers that need to send themselves messages,
and is, by its nature, a very limited case.
3 Use the name-location functions (name_attach() and name_detach(), and then
the name_open() and name_close() functions on the client side).
4 Take over a portion of the pathname space and become a resource manager.
We’ll talk about this when we look at resource managers in the Resource
Managers chapter.
The first approach is very simple, but can suffer from “pathname pollution,” where the
/etc directory has all kinds of *.pid files in it. Since files are persistent (meaning
they survive after the creating process dies and the machine reboots), there’s no
102 Chapter 2 • Message Passing April 30, 2009