Date: Wed, 14 Jul 2004 12:11:18 -0700 From: Alfred Perlstein <alfred@freebsd.org> To: Doug Rabson <dfr@nlsystems.com> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern kern_event.c src/sys/sys eventvar.h Message-ID: <20040714191118.GF95729@elvis.mu.org> In-Reply-To: <200407142001.25615.dfr@nlsystems.com> References: <Pine.NEB.3.96L.1040714145151.56002C-100000@fledge.watson.org> <200407142001.25615.dfr@nlsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* 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'm sure that was a fun panic to hit. :) > > > > Thrilling :-). Actually, I didn't hit the panic, I merely reasoned > > that it might exist and then read more kqueue code than I've read in > > a while > > > > :-). > > : > > > 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. ? -- - Alfred Perlstein - Research Engineering Development Inc. - email: bright@mu.org cell: 408-480-4684
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040714191118.GF95729>