client notification: proxy replacement with ionotify?

QNX Newsgroups (Archives) qdn.public.porting
1

I’m trying to port a resource manager for a data acquisition board
that reads the board, then notifies clients when enough data is ready
for them to read. This was formerly done using proxies: saving a list
of client processes ids and triggering a proxy each time there was
enough data. I was looking at the ionotify set of functions to
re-implement this functionality, and have met with limited success. I
am finding the documentation a little confusing on several points.

1.) It seems like the client must re-call ionotify() after it receives
a pulse triggered by the server. Am I correct? Can I make my client
register for permanent notification within this framework?

2.) The iofunc_notify_t array given to iofunc_notify() and
iofunc_notify_trigger() seems like it should be able to arm
notifications for multiple clients (iofunc_notify_t has a count and
list fields), yet in the documentation of iofunc_notify() it says
under possible returns “EBUSY - A notification was already armed for
this resource, and this library function enforces a restriction of one
per resource.”

Can only 1 client (at a time) register to receive a notification pulse
using this set of functions?

For my stated goals, would I be better off just using pulses that my
server sends directly to implement this functionality?

Thanks in advance for any help any of you can give me.

Pete

2

Peter Jones <pwjones@cns.bcm.tmc.edu> wrote:

I’m trying to port a resource manager for a data acquisition board
that reads the board, then notifies clients when enough data is ready
for them to read. This was formerly done using proxies: saving a list
of client processes ids and triggering a proxy each time there was
enough data. I was looking at the ionotify set of functions to
re-implement this functionality, and have met with limited success. I
am finding the documentation a little confusing on several points.

I can understand that.

1.) It seems like the client must re-call ionotify() after it receives
a pulse triggered by the server. Am I correct? Can I make my client
register for permanent notification within this framework?

Yes, I think that you must re-register after each notification within
this framework.

2.) The iofunc_notify_t array given to iofunc_notify() and
iofunc_notify_trigger() seems like it should be able to arm
notifications for multiple clients (iofunc_notify_t has a count and
list fields), yet in the documentation of iofunc_notify() it says
under possible returns “EBUSY - A notification was already armed for
this resource, and this library function enforces a restriction of one
per resource.”

Can only 1 client (at a time) register to receive a notification pulse
using this set of functions?

Multiple clients can receive notification – I tested this and it
works.

The notification need not be a pulse – it could be a signal if the
client prefers, with no code change on the server side.

I’m not sure what that “EBUSY” errno warning is talking about.

For my stated goals, would I be better off just using pulses that my
server sends directly to implement this functionality?

Servers don’t usually have connections to pulses, so directly using
pulses isn’t your best bet. Stay with MsgDeliverEvent for the
notification delivery. Have the client register a sigevent structure
with you using some sort of message – devctl() or _IO_MSG are good
ways to do this – then save the rcvid(s) and sigevent structure(s),
and MsgDeliverEvent() on each of them.

One advantage, though, of using the ionotify() is that select() is
implemented on top of ionotify(), so you get that behaviour automatically.

But, for your purposes, a custom solution might be better and cleaner
since you want that automatic notification roll-over.

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.