From owner-freebsd-arch@FreeBSD.ORG Wed Dec 13 03:28:52 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9197C16A403; Wed, 13 Dec 2006 03:28:52 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1-3.pacific.net.au [61.8.2.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id 67BE443CA7; Wed, 13 Dec 2006 03:27:25 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout1.pacific.net.au (Postfix) with ESMTP id 11ABE5A3F5C; Wed, 13 Dec 2006 14:28:17 +1100 (EST) Received: from besplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (Postfix) with ESMTP id 817638C0C; Wed, 13 Dec 2006 14:28:15 +1100 (EST) Date: Wed, 13 Dec 2006 14:28:15 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: David Xu In-Reply-To: <200612130730.10973.davidxu@freebsd.org> Message-ID: <20061213141257.J2006@besplex.bde.org> References: <32874.1165905843@critter.freebsd.dk> <200612130730.10973.davidxu@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "Arne H. Juul" , Daniel Eischen , Poul-Henning Kamp , freebsd-arch@freebsd.org, Kostik Belousov , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2006 03:28:52 -0000 On Wed, 13 Dec 2006, David Xu wrote: > 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. A signal would be fast enough for revoke() since revoke() is not used much, and would work well if the signal could be sent, and is unmaskable, and all device drivers catch signals (oops, all of them act like applications whose signal catching function just sets a flag, except while they sleep, so they have the usual problems with just setting a flag -- they may run for too long before actually using the setting). However, I think there is no way to determine which threads are using an fd short of doing the equivalent of fstat(1) searching throuhj kmem. Kernel data structures just aren't set up to do this search efficiently, and shouldn't be bloated to do it. For close() on non-devices, there is the additional problem of infinite disk waits due to things like nfs servers down and bugs. Then signals don't work and you wouldn't like close() by a thread trying to clean up the problem to hang too. Otherwise close()/revoke() would be a good way to cancel an infinite disk wait. Bruce