On Wed, 15 Sep 1999, Christopher Sedore wrote: > My ideas for this are a little different than what I've seen proposed thus > far, more along the lines of creating something that acts as both an event > queue and a IOCP. Ideally this would be a descriptor that could be shared > across processes (or threads), and could be accessed using read(). I > don't much care for the suggestion that threads ought to have an event > queue of their own--rather if you want a per-thread completion > notification, simply create a descriptor for each thread that needs this > function. What ever is created, it should be sufficiently extensible to > allow for all the events we can imagine now, as well as being flexible for > future enhancement. (FWIW, I've also been thinking that I might like to > be able to submit aio requests by write()ing said descriptor. Just a > thought.)
I thought it'd be very useful to be able to give the kernel a pointer to a pollfd struct in your (userland) address space, when events occur SIGIO (or maybe some other signal?) is posted to the process after updating the process's pollfd. This makes queing not nessesary because if a signal is 'lost' somehow the pollfd is still updated, it also reduces the amount of syscalls needed by at least one.
