nextupprevious

RT Signal Issues and Enhancement

Can have lots of queued events for a single fd---lack of fairness.

Queue can get filled up and events get lost---a notification leak. Process gets a SIGIO signal and then is forced to take an alternate action such as select(). Both ugly and complex.

Signal-per-fd idea is to not enqueue more than one RT signal per fd. Limits the size of event queue to the number of fds. Coalesces signals similar to API proposed by Banga and Mogul.

Point out that deciding to add events to the queue can still be done in constant time.

Indicates there were events on fd, not how many.

Question of how to handle read from fd because there could be much available data. Stop reading when less than a buffer is read?