From owner-freebsd-java@FreeBSD.ORG Wed Dec 13 07:12:26 2006 Return-Path: X-Original-To: freebsd-java@freebsd.org Delivered-To: freebsd-java@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2B4B416A407 for ; Wed, 13 Dec 2006 07:12:26 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outQ.internet-mail-service.net (outQ.internet-mail-service.net [216.240.47.240]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7123243CCE for ; Wed, 13 Dec 2006 07:10:39 +0000 (GMT) (envelope-from julian@elischer.org) Received: from shell.idiom.com (HELO idiom.com) (216.240.47.20) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Tue, 12 Dec 2006 22:57:09 -0800 Received: from [192.168.2.4] (home.elischer.org [216.240.48.38]) by idiom.com (8.12.11/8.12.11) with ESMTP id kBD7C23r098829; Tue, 12 Dec 2006 23:12:03 -0800 (PST) (envelope-from julian@elischer.org) Message-ID: <457FA7C0.408@elischer.org> Date: Tue, 12 Dec 2006 23:12:00 -0800 From: Julian Elischer User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Bruce Evans References: <32874.1165905843@critter.freebsd.dk> <200612130730.10973.davidxu@freebsd.org> <20061213141257.J2006@besplex.bde.org> In-Reply-To: <20061213141257.J2006@besplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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-java@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting Java to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2006 07:12:26 -0000 Bruce Evans wrote: > 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. that's processes.. which thread in the process is the one that is currently waiting on the socket? > > 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 > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"