From owner-freebsd-arch@FreeBSD.ORG Mon Jul 7 16:33:23 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 44E3A1065674 for ; Mon, 7 Jul 2008 16:33:23 +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 1C0AC8FC23 for ; Mon, 7 Jul 2008 16:33:22 +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 75DA146C16; Mon, 7 Jul 2008 12:33:22 -0400 (EDT) Date: Mon, 7 Jul 2008 17:33:22 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Poul-Henning Kamp In-Reply-To: <6882.1215446754@critter.freebsd.dk> Message-ID: <20080707173102.L63144@fledge.watson.org> References: <6882.1215446754@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@FreeBSD.org, Sergey Babkin Subject: 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 16:33:23 -0000 On Mon, 7 Jul 2008, Poul-Henning Kamp wrote: > In message <20080707162733.V63144@fledge.watson.org>, Robert Watson writes: > >>>> achieve something of the same end by opening /dev/null and then >>>> dup2()'ing to the file descriptor you want to revoke, perhaps? Right now >>>> there's a known >>> >>> That's a great idea. I haven't thought about it. It should do everything. >> >> Right, and possibly this means that no additional kernel support is >> required -- we just make it a libc or libutil interface. > > I can't see how that could possibly work... > > If you do a dup2(), the original fd is closed, and that still does not > release all threads that may be sleeing on it in device drivers. I see interrupting current consumers as a separable issue from invalidating the file descriptor for future users. I'm not convinced there's a good general solution for interrupting current consumers of a file descriptor -- we can improve the semantics for a few objects (i.e., sockets) if required, but I'm not sure it generalizes well. For sockets, generally speaking, calling shutdown(2) is the approved way to initiate a disconnect, which will lead to other consumers being kicked out of operations on the file descriptor, rather than close(2), which in general doesn't initiate a disconnect because it's a reference count operation on the underlying object. Robert N M Watson Computer Laboratory University of Cambridge