From owner-cvs-all@FreeBSD.ORG Wed Jul 14 19:06:40 2004 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 31E9316A4CE; Wed, 14 Jul 2004 19:06:40 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id D20E243D5F; Wed, 14 Jul 2004 19:06:37 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-63-195-111-154.dsl.snfc21.pacbell.net [63.195.111.154]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id i6EJ6arb018547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 14 Jul 2004 12:06:36 -0700 Message-ID: <40F58403.5020600@root.org> Date: Wed, 14 Jul 2004 12:05:39 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Doug Rabson References: <200407142001.25615.dfr@nlsystems.com> In-Reply-To: <200407142001.25615.dfr@nlsystems.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: cvs-src@FreeBSD.org cc: Alfred Perlstein cc: Robert Watson cc: cvs-all@FreeBSD.org cc: src-committers@FreeBSD.org Subject: Re: cvs commit: src/sys/kern kern_event.c src/sys/sys eventvar.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2004 19:06:40 -0000 Doug Rabson 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. In fact, the AIO task threads already provide a convenient context for this. -- -Nate