select() actually IS edge triggered
Posted Mar 15, 2003 8:18 UTC (Sat) by IkeTo
In reply to: select() actually IS edge triggered
Parent article: Edge-triggered interfaces are too difficult?
> (This has nothing to do with what the standards
> might say. Most programs are coded to run on
> machines, not on standards :-)
Except perhaps to determine who is broken and thus must change. :-)
BTW, I see the implementation of Linux select() as to call a "poll method" of the device driver at the beginning to ask what is the current device status, and then, if it is not ready, to wait on a wait queue which is woken up by various device driver routines via the poll_wait() interface. Upon wake up the device is checked again for ready operations. Under this implementation I see no reason why a device can be edge-triggered: the device driver simply has to do much more work to make it edge-trigger without introducing a lot of race conditions.
On the other hand, if there are really device out there that *is* edge triggered on select(), then the advice that "one must read/write the fd if you select() it" is not sufficient. Instead, the advice should be "one must set the fd to non-blocking and read/write all the ready fds until it returns -1 with errno=EAGAIN or errno=EINTR, or you no longer need to read and write the fd, in which case you must no longer select() on them". Personally I've never seen a single scenario when the latter is needed. The former is always needed, for the simple reason that if you never read/write a fd that you select(), then once the fd is ready, it is always ready and break select(), so select() becomes a very expensive form of busy-polling.
to post comments)