From owner-freebsd-java@FreeBSD.ORG Wed Dec 13 12:10:54 2006 Return-Path: X-Original-To: freebsd-java@freebsd.org Delivered-To: freebsd-java@freebsd.org Received: from localhost.my.domain (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id B4BE516A416; Wed, 13 Dec 2006 12:10:53 +0000 (UTC) (envelope-from davidxu@freebsd.org) From: David Xu To: freebsd-java@freebsd.org, Daniel Eischen Date: Wed, 13 Dec 2006 20:10:49 +0800 User-Agent: KMail/1.8.2 References: <32874.1165905843@critter.freebsd.dk> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200612132010.49601.davidxu@freebsd.org> Cc: Kostik Belousov , Poul-Henning Kamp , "Arne H. Juul" , Bruce Evans , freebsd-arch@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 12:10:54 -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). Even if you have implemented the close() with the interruption, another thread openning a file still can reuse the file handle immediately, according to specifications, the lowest free file handle will be returned, if SA_RESTART is used, the interrupted thread restart the syscall, it will be using a wrong file, I think even if we have implemented the feature in kernel, useland threads still has serious race to fix. David Xu