lio_listio fixes and adding kqueue notification patch

Doug Ambrisko ambrisko at ambrisko.com
Wed Mar 16 15:48:18 PST 2005


John-Mark Gurney writes:
| Doug Ambrisko wrote this message on Fri, Oct 22, 2004 at 08:42 -0700:
| > BTW this could show my own ignorance since I don't think this exists.
| > What would be nice is if a signal could be associated with kevents 
| > happening.  The idea would be that instead of polling for kevents that 
| > a signal handler could be setup to notify the process when a kevent 
| > just happened.  The usage would be to set a tell kqueue to signal a 
| > certain signal if any kevent events occur.  This would allow a program
| > not to be just focused on I/O but allow a bunch of computation to 
| > happen then deal with I/O without polling for it.  Not every app.
| > is just a "bit pusher".
| 
| I'm looking at this problem now, but I thought I might as well respond
| to this...

Note that it would be nice just to have AIO & kqueue working.  Currently
it is broken in 5.3+ & 6.X.  FWIW I checked in an aio & kqueue test
into the regressions.  There is an lio version that depends on my lio 
patch to implement that.  I also have a version that I was playing around
with that randomly did aio_cancels.

| There is a problem with that in that you could have a kqueue (possibly
| the same kq) that has an event when that signal is delivered.. this would
| then attempt to deliver and end up recursing on the lock... I have
| fixed this wrt kq in a kq, but I haven't investigated trying to make
| signals delivery work..
| 
| You can look at the FIOASYNC code Alfred commited to use the signal on
| fd ready a while back, but is if 0'd because of this issue...  It would
| probably be easy enough to create another task that does the signal
| delivery if you want...  so when a kq becomes ready, it init's a task
| to deliver the signal...

I recall his commit but haven't really looked at it.  It would be nice
to have.

Doug A.


More information about the freebsd-current mailing list