From owner-cvs-src@FreeBSD.ORG Wed Jul 14 18:44:45 2004 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B7E6A16A4CE; Wed, 14 Jul 2004 18:44:45 +0000 (GMT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id A7D8743D2F; Wed, 14 Jul 2004 18:44:45 +0000 (GMT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 9CA745C89B; Wed, 14 Jul 2004 11:44:45 -0700 (PDT) Date: Wed, 14 Jul 2004 11:44:45 -0700 From: Alfred Perlstein To: Robert Watson Message-ID: <20040714184445.GC95729@elvis.mu.org> References: <200407140702.i6E724mV093920@repoman.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern kern_event.c src/sys/sys eventvar.h X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2004 18:44:45 -0000 * Robert Watson [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