From owner-freebsd-arch@FreeBSD.ORG Wed Dec 13 14:23:25 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 0C44716A403; Wed, 13 Dec 2006 14:23:25 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6336843CA4; Wed, 13 Dec 2006 14:21:55 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.8/8.13.8/NETPLEX) with ESMTP id kBDENNe8029216; Wed, 13 Dec 2006 09:23:23 -0500 (EST) Date: Wed, 13 Dec 2006 09:23:23 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: David Xu In-Reply-To: <200612132010.49601.davidxu@freebsd.org> Message-ID: References: <32874.1165905843@critter.freebsd.dk> <200612132010.49601.davidxu@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-3.0 (mail.ntplx.net [204.213.176.10]); Wed, 13 Dec 2006 09:23:23 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: freebsd-arch@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 Reply-To: Daniel Eischen 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 14:23:25 -0000 [CC trimmed] On Wed, 13 Dec 2006, David Xu wrote: > On Wednesday 13 December 2006 04:49, Daniel Eischen wrote: >> >> 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. If you use a special signal that is only used for this purpose, there is no reason you have to try the IO operation again. You can just return EBADF. Anyway, this was just a thought/idea. I don't mean to argue against any of the other reasons why this isn't a good idea. -- DE