From owner-freebsd-arch@FreeBSD.ORG  Tue Dec 12 23:30:13 2006
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
X-Original-To: freebsd-arch@freebsd.org
Delivered-To: freebsd-arch@freebsd.org
Received: from localhost.my.domain (localhost [127.0.0.1])
	by hub.freebsd.org (Postfix) with ESMTP id 73A0D16A51E;
	Tue, 12 Dec 2006 23:30:13 +0000 (UTC)
	(envelope-from davidxu@freebsd.org)
From: David Xu <davidxu@freebsd.org>
To: Daniel Eischen <deischen@freebsd.org>
Date: Wed, 13 Dec 2006 07:30:10 +0800
User-Agent: KMail/1.8.2
References: <32874.1165905843@critter.freebsd.dk>
	<Pine.GSO.4.64.0612121543220.8780@sea.ntplx.net>
In-Reply-To: <Pine.GSO.4.64.0612121543220.8780@sea.ntplx.net>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200612130730.10973.davidxu@freebsd.org>
Cc: "Arne H. Juul" <arnej@pvv.ntnu.no>, Poul-Henning Kamp <phk@phk.freebsd.dk>,
	freebsd-arch@freebsd.org, Kostik Belousov <kostikbel@gmail.com>,
	freebsd-java@freebsd.org
Subject: Re: close() of active socket does not work on FreeBSD 6
X-BeenThere: freebsd-arch@freebsd.org
X-Mailman-Version: 2.1.5
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: Tue, 12 Dec 2006 23:30:13 -0000

On Wednesday 13 December 2006 04:49, Daniel Eischen wrote:
> On Tue, 12 Dec 2006, Poul-Henning Kamp wrote:
> > In message <20061212160016.W56465@delplex.bde.org>, Bruce Evans writes:
> >> On Mon, 11 Dec 2006, Daniel Eischen wrote:
> >>
> >> It's probably a nightmare in the kernel too.  close() starts looking
> >> like revoke(), and revoke() has large problems and bugs in this area.
> >
> > There is the distinctive difference that revoke() operates on a name
> > and close() on a filedescriptor, but otherwise I agree.
>
> Well, if threads waiting on IO are interruptable by signals,
> can't we make a new signal that's only used by the kernel
> and send it to all threads waiting on IO for that descriptor?
> When it gets out to actually setup the signal handler, it
> just resumes like it is returning from an SA_RESTART signal
> handler (which according to another posting would reissue
> the IO command and get EBADF).

Stop using signal, it is slow for threaded process, first you don't
know which threads are using the descriptor, second, you have
to run long code path in kernel signal code to find and deliver
the signals to all interested threads, that is too expensive for
benchmark like apache benchmark.

David Xu