Date: Wed, 14 Jul 2004 12:29:00 -0700 From: Nate Lawson <nate@root.org> To: Alfred Perlstein <alfred@freebsd.org> Cc: cvs-src@freebsd.org Subject: Re: cvs commit: src/sys/kern kern_event.c src/sys/sys eventvar.h Message-ID: <40F5897C.7010904@root.org> In-Reply-To: <20040714191118.GF95729@elvis.mu.org> References: <Pine.NEB.3.96L.1040714145151.56002C-100000@fledge.watson.org> <200407142001.25615.dfr@nlsystems.com> <20040714191118.GF95729@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Alfred Perlstein wrote: > * Doug Rabson <dfr@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40F5897C.7010904>