From owner-freebsd-arch@FreeBSD.ORG  Tue Jul  8 16:46:16 2008
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
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 C9CB6106564A
	for <arch@FreeBSD.ORG>; Tue,  8 Jul 2008 16:46:16 +0000 (UTC)
	(envelope-from das@FreeBSD.ORG)
Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101])
	by mx1.freebsd.org (Postfix) with ESMTP id 881FB8FC1E
	for <arch@FreeBSD.ORG>; Tue,  8 Jul 2008 16:46:16 +0000 (UTC)
	(envelope-from das@FreeBSD.ORG)
Received: from zim.MIT.EDU (localhost [127.0.0.1])
	by zim.MIT.EDU (8.14.2/8.14.2) with ESMTP id m68Gmswu040786;
	Tue, 8 Jul 2008 12:48:54 -0400 (EDT) (envelope-from das@FreeBSD.ORG)
Received: (from das@localhost)
	by zim.MIT.EDU (8.14.2/8.14.2/Submit) id m68Gmr08040785;
	Tue, 8 Jul 2008 12:48:53 -0400 (EDT) (envelope-from das@FreeBSD.ORG)
Date: Tue, 8 Jul 2008 12:48:53 -0400
From: David Schultz <das@FreeBSD.ORG>
To: Robert Watson <rwatson@FreeBSD.ORG>
Message-ID: <20080708164853.GA40704@zim.MIT.EDU>
Mail-Followup-To: Robert Watson <rwatson@FreeBSD.ORG>,
	Sergey Babkin <babkin@verizon.net>, arch@FreeBSD.ORG,
	Poul-Henning Kamp <phk@phk.freebsd.dk>
References: <9484951.340521215467447990.JavaMail.root@vms126.mailsrvcs.net>
	<20080708001929.E63144@fledge.watson.org>
	<20080708161802.N89342@fledge.watson.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20080708161802.N89342@fledge.watson.org>
Cc: arch@FreeBSD.ORG, Poul-Henning Kamp <phk@phk.freebsd.dk>,
	Sergey Babkin <babkin@verizon.net>
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 <freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Jul 2008 16:46:16 -0000

On Tue, Jul 08, 2008, Robert Watson wrote:
> These sorts of edge cases, btw, are one reason why I would *strongly* 
> discourage application writers from doing things like calling close(2) on a 
> file descriptor while still using it from another thread. :-)

My reaction is that apps should use standard concurrency control
primitives, e.g., pthreads primitives or message queues, to
coordinate the activities of multiple threads. The are scads of
ways to introduce race conditions when updating various aspects of
the process state (the fd table, in this case). Once we start
adding special-purpose APIs to facilitate clever lock-free tricks
in very specific cases, when will it stop? Next we'll want a
special version of exit(), a special version of sigaction(), a
special version of free(), and so forth.

That said, POSIX does require open() and close() to be atomic, so
the Linux emulation layer should be fixed in that regard:

  2.9.7 Thread Interactions with Regular File Operations
  
  All of the functions chmod(), close(), fchmod(), fcntl(), fstat(),
  ftruncate(), lseek(), open(), read(), readlink(), stat(),
  symlink(), and write() shall be atomic with respect to each other
  in the effects specified in IEEE Std 1003.1-2001 when they operate
  on regular files. If two threads each call one of these functions,
  each call shall either see all of the specified effects of the
  other call, or none of them.