You are getting a pulse code 0 from somewhere else (i.e. not as the result of your MsgSendPulse). You can simply check that pulse.code == _PULSE_CODE_MAXAVAIL before checking the sival_int for your command.
I have a question about MsgSendPulse().
According to QNX documentation, MsgSendPulse() sends “a tiny non-blocking message (pulse)”. I am not sure I understand the term “non-blocking”.
I thought “non-blocking” means if there is no process calling MsgReceivePulse(), the pulse will be discarded.
From this link: qnx.com/developers/docs/mome … pulse.html
“Pulses are queued for the receiving process in the system, …”
So the pulses are saved, instead of being discarded.
How can I discard the pulses, if no process is waiting for the pulse? This is the requirement of my application.
Or how can the receiver clear all the pulse in the queue and wait for the next pulse?
“non-blocking” means that MsgSendPulse will return after sending the pulse what ever the state of the receiving end. A block call means it will block until the receiving end indicates it is done with the message.
You cannot discard pulses, you need to either consume them, or close the channel they were send on and open a new one.
I think this is a short coming in the OS. Under QNX4 it’s possible to clear the pulses (proxy) queue on a per proxy basis.
^
||
||
Do you refer to the QNX4 function Creceive()?
There is an article saying that Creceive function can be implemented in QNX6 with:
MsgReceive() preceded immediately by:
The sender in my application generates events at certain frequencies.
When the receiver wakes up, it is only interested in events that happens later, disregarding previous events.
If pulses don’t work, is there any other mechanism can realize this functionality?
Creceive can be partly emulated yes, but receive() and Creceive() have the ability to receive only from a specify process or proxy, that cannot be done with TimerTimeout.
Hence MsgReceivePulse will receive ALL pulses. But if all you will be receiving on that channel is that single pulse then it’s doable.
If not maybe if you can send some sort of time stamp along with the pulse so that the receiver can tell wether they should be disregarded or not.
This already sounds like bad design. What does it mean that the receiver wakes up? Wake up from a MsgReceive? If so, how can it be interested in events that happen later. That would be events in the future right?
Let’s assume that you mean later than some time in the past. What is the resolution? Clearly if the resolution is 1 second, the sender could send the value of time() along in the pulse. If the resolution is finer, then you will have to be a bit careful in case there is a roll over issue.
Why does the sender need to be unblocked immediately? Another way of thinking about a pulse, is that there is an invisible queueing mechanism in the OS. Maybe you need a queueing mechanism that isn’t limited to the package size that a pulse sends.
I’ve often run into the fear, and misunderstanding, that such an arrangement would not create the same affect, non-blocking, but
there is really no difference if engineered right. Sending a Pulse involves a kernel call, just like a MsgSend. If the queueing thread is at a higher priority, it runs immediately, queues the message, and the client is running again. A pulse is more efficient in that the OS doesn’t have to schedule another process, but it still has to queue the pulse.
Either way the results are the same except for the latency, which is small in both cases.