I’ve got my resmgr to support select, it appears to be working but not
quite:
A little background; the resmgr keeps a list of ocb in each attribute. That
way
if an event occurs each ocb that opened that device can be notify. My loop
for
notification looks like this:
for ( i = 0 ; i< NB_ID; i++ ) {
for ( j = 0 ; j < sw_attr_.nb_alloc_ocb; j++ ) {
if ( sw_attr.ocb[j] != NULL ) {
dprintf(2,“OCB %d %d\n”, i,j );
if ( sw_attr.ocb[j]->pending_notify && (which_switch &
sw_attr.mask) ) {
dprintf(2,“Notify\n”);
sw_attr.ocb[j]->pending_notify = 0;
iofunc_notify_trigger ( sw_attr.ocb[j]->nop, 1,
IOFUNC_NOTIFY_OBAND );
}
}
}
}
My client test program open 3 file descriptions each on different
path/device (handle by the same
resmgr).
The dprintf is a printf that print only if verbose level is equal or greater
then first argument. If verbosity
level is set to 0, all works fine and upon a single event all 3 files
descriptor get notify. That is select()
returns 3 and all FD are set.
If the level of verbosity is 2 (dprintf prints), select returns 1 but no FD
are set???
Playing with priority does change behavior. If resmgr is set above that of
client it
works fine. I guess the printf changes the timing, thus affecting the
sequence of event
between the client’s select and the resmgr’ iofunc_notify_trigger.
I though I understood how select/io_notify worked, but those printf are
proving otherwise 
I’ve also been wondering, when the client is out of select, how does the
resmgr knows
not to notify the client anymore?
\
- Mario_