From owner-freebsd-arch@FreeBSD.ORG Mon Jul 7 23:23:02 2008 Return-Path: Delivered-To: arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2EAED1065671; Mon, 7 Jul 2008 23:23:02 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 04AF48FC21; Mon, 7 Jul 2008 23:23:01 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 7D74546C81; Mon, 7 Jul 2008 19:23:01 -0400 (EDT) Date: Tue, 8 Jul 2008 00:23:01 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Sergey Babkin In-Reply-To: <9484951.340521215467447990.JavaMail.root@vms126.mailsrvcs.net> Message-ID: <20080708001929.E63144@fledge.watson.org> References: <9484951.340521215467447990.JavaMail.root@vms126.mailsrvcs.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@FreeBSD.ORG, David Schultz , Poul-Henning Kamp Subject: Re: Re: Re: Proposal: a revoke() system call 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: Mon, 07 Jul 2008 23:23:02 -0000 On Mon, 7 Jul 2008, Sergey Babkin wrote: > This leaves a small race window between fd is checked and read() is > executed. If in the meantime another thread does close() (and sets > mystructure.fd to -1), and the third thread does open() then the result of > this open would use the same fd number as our old fd (since now it's likely > to be the lowest available number), then read() would happen on a completely > wrong file. And yes, it does happen in real world. The best workaround I've > come up with is a small pause between setting mystructure.fd = -1 and > calling close(). > > The point of proposal is to do a close() without freeing the file > descriptor. Which can be accomplished by calling dup2(2) to replace the file descriptor with another file descriptor, perhaps one to /dev/null. It would be worth carefully reviewing the implementation of dup2(2) to make sure that the close->replace there is atomic with respect to other threads simultaneously allocating file descriptors, such as with pipe(2). This won't cancel existing I/Os, but per discussion, I/O cancelation is a very complicated issue. Robert N M Watson Computer Laboratory University of Cambridge