From owner-freebsd-arch@FreeBSD.ORG  Fri Apr  9 07:39:18 2004
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id 55FFE16A4CE; Fri,  9 Apr 2004 07:39:18 -0700 (PDT)
Received: from fledge.watson.org (fledge.watson.org [204.156.12.50])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id D5B2143D39; Fri,  9 Apr 2004 07:39:17 -0700 (PDT)
	(envelope-from robert@fledge.watson.org)
Received: from fledge.watson.org (localhost [127.0.0.1])
	by fledge.watson.org (8.12.10/8.12.10) with ESMTP id i39EcrPq063893;
	Fri, 9 Apr 2004 10:38:54 -0400 (EDT)
	(envelope-from robert@fledge.watson.org)
Received: from localhost (robert@localhost)i39Ecrej063890;
	Fri, 9 Apr 2004 10:38:53 -0400 (EDT)
	(envelope-from robert@fledge.watson.org)
Date: Fri, 9 Apr 2004 10:38:53 -0400 (EDT)
From: Robert Watson <rwatson@FreeBSD.org>
X-Sender: robert@fledge.watson.org
To: Seigo Tanimura <tanimura@tanimura.dyndns.org>
In-Reply-To: <200404090853.i398rwAq029617@urban>
Message-ID: <Pine.NEB.3.96L.1040409103002.62857B-100000@fledge.watson.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
cc: Pawel Jakub Dawidek <pjd@FreeBSD.org>
cc: freebsd-arch@FreeBSD.org
Subject: Re: mtx_lock_recurse/mtx_unlock_recurse functions
	(proof-of-concept).
X-BeenThere: freebsd-arch@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Discussion related to FreeBSD architecture
	<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Apr 2004 14:39:18 -0000


On Fri, 9 Apr 2004, Seigo Tanimura wrote:

> (3) Let a dedicated kernel thread call the methods of struct
>     filterops.  
> 
> The headache of kqueue is that KNOTE() ultimately calls back the caller
> subsystem.  Tty would suffer from the same pain as well. 
> 
> Assuming that a kqueue event need not be delivered synchronously upon
> the event, maybe we can attach an event queue to a knote list.  KNOTE()
> appends an event to the queue and wakes up a dedicated kernel thread
> (kqueued).  It then dequeues the event in a queue to call a filter
> *without* the lock of the event source. (socket, tty, etc.) 

Such an approach would be fine by me, but it would also have some
complications.  For example, we need to make sure we handle the case where
a kqueue event thread wakes up to handle a socket event, but the socket
has been free'd.  It's not all that bad, it just involves a necessary
amount of paperwork as well.  It does seem that the fundamental problem
here is that KQueue is one of the more incestuous of support subsystems in
the kernel, and a little bit of redesign might well be called for, because
it will simplify the locking, but probably also clean up other concerns.
The MAC Framework is also an incestuous subsystem, but it does a lot less
"calling back" than KQueue does.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert@fledge.watson.org      Senior Research Scientist, McAfee Research