Date: Wed, 14 Jul 2004 11:44:45 -0700 From: Alfred Perlstein <alfred@freebsd.org> To: Robert Watson <rwatson@FreeBSD.org> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern kern_event.c src/sys/sys eventvar.h Message-ID: <20040714184445.GC95729@elvis.mu.org> In-Reply-To: <Pine.NEB.3.96L.1040714103934.83353K-100000@fledge.watson.org> References: <200407140702.i6E724mV093920@repoman.freebsd.org> <Pine.NEB.3.96L.1040714103934.83353K-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
* Robert Watson <rwatson@FreeBSD.org> [040714 07:43] wrote: > > On Wed, 14 Jul 2004, Alfred Perlstein wrote: > > > Log: > > Make FIOASYNC, FIOSETOWN and FIOGETOWN work on kqueues. > > Have you tried testing this on a kqueue used to monitor signals? I'd draw > your particular attention to the following newly enabled code path: > > pgsigio() -> psignal() -> tdsignal() -> do_tdsignal() -> KNOTE() -> > knote() -> KNOTE_ACTIVATE() -> knote_enqueue() -> kqueue_wakeup() -> > pgsigio() > > It strikes me that adding sigio support to kqueue opens a massive can of > worms, not least of which is how you prevent the above from causing the > system to panic, not to mention how you handle locking in what is > otherwise a set of leaf functions in kqueue. I'd like it if you could > back this out until locking for kqueue is resolved, as while this is no > doubt a useful feature, having the locking working is much more useful to > us for 5.3. I'm sure that was a fun panic to hit. :) I can fix this by setting a "sigio in progress" on the kqeue and not calling pgsigio() while one is in progress. As far as the locking, we can address that when locking for kqueues are done, with the idea that SIGIO _should_ work for kqueues. Do we have this on the plate? Or are you stalling my work based simply on wishful thinking? :) -- - 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?20040714184445.GC95729>