Date: Wed, 13 Dec 2006 22:28:03 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Julian Elischer <julian@elischer.org> Cc: "Arne H. Juul" <arnej@pvv.ntnu.no>, Daniel Eischen <deischen@FreeBSD.org>, Poul-Henning Kamp <phk@phk.freebsd.dk>, David Xu <davidxu@FreeBSD.org>, 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 Message-ID: <20061213220952.H792@besplex.bde.org> In-Reply-To: <457FA7C0.408@elischer.org> References: <32874.1165905843@critter.freebsd.dk> <Pine.GSO.4.64.0612121543220.8780@sea.ntplx.net> <200612130730.10973.davidxu@freebsd.org> <20061213141257.J2006@besplex.bde.org> <457FA7C0.408@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061213220952.H792>