In the example you give, you have cat get a handle and then issue a read.
It seems you want cat to block indefinitely, but for the resource manager to return a growing amount of data over time.
I have two comments:
As mario mentioned you can setup a periodic timer to the resource manager to (perhaps) check for new data.
There are no potential savings wrt number of reads issued (at least in the example you provide) because in order for cat to display something the read must return, and then cat will issue another read.
Ignoring that there is no advantage wrt number of reads issued, the behavior you desire is easily achieved, simply by never returning 0 (as the result of a read) to cat. The cat utility will only see EOF when you return a zero, so if you alway return something or don’t reply at all (until the next timer fires perhaps) then you’ll get the behavior that I think you are seeking…
Thanks for the answers. I realised that it does not make a big difference, if the client sends always some reads and is blocked until a reply comes or using pulses in a strange way .
But my other problem is: When do I use which layer (resmgr, iofunc, dispatch…)? I am a little bit stuck right now. I have a measurement card for pci, it shall deliver some kind of trigger-signal periodically, e.g. read on /dev/pulse blocks the client until the hardware does an interrupt (hardware interrupts work etc.). First I thought it would be useful to do it with pulses because no data should be transmitted, but since pulses are none-blocking, I guess this won’t work. Or is ist possible, that the client first makes an open() on /dev/pulse and then msgreceivepulse()? Thanks
It sounds as if you are new to QNX. In this case, I would suggest that you always use resmgr layer for now.
To have an app block on /dev/pulse and then wake up when an interrupt arrives, simply don’t reply to the app until the interrupt occurs, at which point return 0. The app will see an EOF, know that something happened (presumably do something), and then return to read where it will block until the next interrupt.
This is certainly used more often, since many clients are non-trivial and don’t want to sit around doing nothing, just waiting to be unblocked. With async notification the client can do other stuff while waiting. That said, I think many people use notification, when the client actually could be trivial and the simple approach that horst was asking about would do just fine.