Hello Everybody,
is it possible that a Resource Manager sends pulses e.g. every 1 sec. , after a client connects making just one read()? I don’t want to have the overhead of sending a read() everytime.
for example it could be like this:
cat /dev/pulse
pulse
pulse (1 sec. later)
pulse (2 sec. later)
.
.
.
I hope you understand what I mean. Thanks.
You can set up a timer and firing the pulse yourself every 1 sec.
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…
I sure feel a bit honored to be compared to mario, but its micro ^^
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
Sorry, just so used to typing “mario”
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.
You might want to look at implement notification. That doesn’t work from the shell ( cat /dev/pulse ) but it will work in any of your own program. Check out io_notify().
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.