cvs commit: src/sys/kern kern_event.c src/sys/sys eventvar.h

[Nate Lawson]

Alfred Perlstein wrote:
> * Doug Rabson <dfr at nlsystems.com> [040714 12:01] wrote:
>>On Wednesday 14 July 2004 19:56, Robert Watson wrote:
>>>On Wed, 14 Jul 2004, Alfred Perlstein wrote:
>>>>I can fix this by setting a "sigio in progress" on the kqeue and
>>>>not calling pgsigio() while one is in progress.
>>>
>>>My worry is the inter-subsystem calling.  We often call KNOTE() while
>>>holding existing locks in the calling subsystem that we can't drop.
>>>Generally, kqueue is a leaf node subsystem in that it's called from
>>>many places under many circumstances, and needs to not disrupt the
>>>calling state by doing "weird things".  What's there before your
>>>change is not too disruptive/weird; afterwards, we call into the body
>>>of the process signalling code which requires additional process
>>>locks.  Note that there are other paths to the same suffering: if any
>>>other signal is delivered to a process that's monitoring for signals
>>>with kqueue causing a sigio, you're still recursing into the signal
>>>subsystem.
>>
>>Seems to me that the best thing to do is to defer the psigio() to a 
>>taskqueue that will run in a simpler locking environment.
> 
> I was thinking that, but I'm worried about "stale delivery",
> perhaps we need to record the generation count (process start time)
> in the sigio as well as the request sent, so that we don't send
> a signal to the wrong process.

Sorry, never mind my previous comments.  I was recently working with 
kqueue AIO notifications and misread AIO for kqueue.  Oops.

-- 
-Nate