Getting Started with QNX Neutrino - QNX Software Systems

© 2009, QNX Software Systems GmbH & Co. KG. Pulses
The MsgDeliverEvent() function
(requests for service). Since you’re trying to control the number of “service-providing
threads,” and since some of these threads may need to block, waiting for a pulse to
arrive (for example, from some hardware or from another thread), you’d typically
block the service-providing thread using MsgReceivePulse(). This ensures that a client
request won’t “sneak in” while you’re waiting for the pulse (since MsgReceivePulse()
will receive only a pulse).
As mentioned above in “The send-hierarchy,” there are cases when you need to break
the natural flow of sends.
Such a case might occur if you had a client that sent a message to the server, the result
might not be available for a while, and the client didn’t want to block. Of course, you
could also partly solve this with threads, by having the client simply “use up” a thread
on the blocking server call, but this may not scale well for larger systems (where you’d
be using up lots of threads to wait for many different servers). Let’s say you didn’t
want to use a thread, but instead wanted the server to reply immediately to the client,
“I’ll get around to your request shortly.” At this point, since the server replied, the
client is now free to continue processing. Once the server has completed whatever task
the client gave it, the server now needs some way to tell the client, “Hey, wake up, I’m
done.” Obviously, as we saw in the send-hierarchy discussion above, you can’t have
the server send a message to the client, because this might cause deadlock if the client
sent a message to the server at that exact same instant. So, how does the server “send”
a message to a client without violating the send hierarchy?
It’s actually a multi-step operation. Here’s how it works:
1 The client creates a struct sigevent structure, and fills it in.
2 The client sends a message to the server, effectively stating, “Perform this
specific task for me, reply right away, and by the way, here’s a struct
sigevent that you should use to notify me when the work is completed.”
3 The server receives the message (which includes the struct sigevent),
stores the struct sigevent and the receive ID away, and replies immediately
to the client.
4 The client is now running, as is the server.
5 When the server completes the work, the server uses MsgDeliverEvent() to
inform the client that the work is now complete.
We’ll take a look in detail at the struct sigevent in the Clocks, Timers, and
Getting a Kick Every So Often chapter, under “How to fill in the struct
sigevent.” For now, just think of the struct sigevent as a “black box” that
somehow contains the event that the server uses to notify the client.
Since the server stored the struct sigevent and the receive ID from the client, the
server can now call MsgDeliverEvent() to deliver the event, as selected by the client, to
the client:
April 30, 2009 Chapter 2 • Message Passing 117