Getting Started with QNX Neutrino - QNX Software Systems

© 2009, QNX Software Systems GmbH & Co. KG. QNX 4 and Neutrino
message under QNX 4 they just did a Receive(). This would block until a message
arrived. The server would then reply with the Reply() function.
Under Neutrino, message passing is identical (different function names, though).
What’s changed is the mechanism. The client now has to create a connection to a
server before it can do the standard message-passing functions. And the server has to
create a channel before it can do the standard message-passing functions.
Note that the QNX 4 Creceive() function, which would do a non-blocking Receive(), is
missing from Neutrino. We generally discourage such “polling” functions, especially
when you can start a thread, but if you really insist on performing a non-blocking
MsgReceive(), you should take a look at the Clocks, Timers, and Getting a Kick Every
So Often chapter (under “Kernel timeouts”) for more information. For the short story
version, here’s the relevant code sample:
TimerTimeout (CLOCK_REALTIME, _NTO_TIMEOUT_RECEIVE,
NULL, NULL, NULL);
rcvid = MsgReceive (...
Pulses and events
QNX 4 provided something called a “proxy.” A proxy is best described as a “canned”
(or “fixed”) message, which could be sent by processes or kernel services (like a timer
or interrupt service routine) to the owner of the proxy. The proxy is non-blocking for
the sender and would arrive just like any other message. The way to identify a proxy
(as opposed to another process actually sending a message) was to either look at the
proxy message contents (not 100% reliable, as a process could send something that
looked like the contents of the proxy) or to examine the process ID associated with the
message. If the process ID of the message was the same as the proxy ID, then you
could be assured it was a proxy, because proxy IDs and process IDs were taken from
the same pool of numbers (there’d be no overlap).
Neutrino extends the concept of proxies with “pulses.” Pulses are still non-blocking
messages, they can still be sent from a thread to another thread, or from a kernel
service (like the timer and ISR mentioned above for proxies) to a thread. The
differences are that while proxies were of fixed-content, Neutrino pulses are
fixed-length, but the content can be set by the sender of the pulse at any time. For
example, an ISR could save away a key piece of data into the pulse and then send that
to a thread.
Under QNX 4, some services were able to deliver a signal or a proxy, while other
services were able to deliver only one or the other. To complicate matters, the delivery
of these services was usually done in several different ways. For example, to deliver a
signal, you’d have to use the kill() function. To deliver a proxy or signal as a result of a
timer, you’d have to use a negative signal number (to indicate it was a proxy) or a
positive signal number (to indicate it was a signal). Finally, an ISR could deliver only
a proxy.
April 30, 2009 Appendix: A • QNX 4 to Neutrino 289