From owner-freebsd-arch@FreeBSD.ORG Wed Dec 13 11:28:29 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 0047E16A508; Wed, 13 Dec 2006 11:28:28 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2-3.pacific.net.au [61.8.2.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id A552743CF7; Wed, 13 Dec 2006 11:26:38 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout2.pacific.net.au (Postfix) with ESMTP id 3B070111229; Wed, 13 Dec 2006 22:28:04 +1100 (EST) Received: from besplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (Postfix) with ESMTP id C9A3E8C0B; Wed, 13 Dec 2006 22:28:03 +1100 (EST) Date: Wed, 13 Dec 2006 22:28:03 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Julian Elischer In-Reply-To: <457FA7C0.408@elischer.org> Message-ID: <20061213220952.H792@besplex.bde.org> References: <32874.1165905843@critter.freebsd.dk> <200612130730.10973.davidxu@freebsd.org> <20061213141257.J2006@besplex.bde.org> <457FA7C0.408@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "Arne H. Juul" , Daniel Eischen , Poul-Henning Kamp , David Xu , 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 11:28:29 -0000 On Tue, 12 Dec 2006, Julian Elischer wrote: > Bruce Evans wrote: >> 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 >> ... >> 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. > > that's processes.. which thread in the process is the one that is currently > waiting on the socket? Do you mean that this wouldn't work the signal would need to be per-thread but signals are per-process? Aren't there per-thread signals now? It's not just one thread, at least for general files. There can be any number. I just remembered that SIGIO delivery has problems near here. There is some i/o on a device, and the kernel has to figure out all open fd's on the device with O_ASYNC set on the open file of the fd. It has difficulty doing this, even with some data structures pointing from the device back to the processes. In theory there can be any number of fd's with the same open file and the signal should be broadcast to the processes owning these fd's). This is still simpler than signaling threads in i/o functions since the signal is broadcast. I said that something like fstat(1) groping in kmem is needed to find all the relevant threads. That is nowhere near enough -- fstat cannot tell which threads are currently in i/o functions. Something closer to what debuggers do is needed -- stop all threads and stack trace them all to see where they are :-). Bruce