Date: Mon, 7 Jul 2008 17:33:22 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: arch@FreeBSD.org, Sergey Babkin <babkin@verizon.net> Subject: Re: Proposal: a revoke() system call Message-ID: <20080707173102.L63144@fledge.watson.org> In-Reply-To: <6882.1215446754@critter.freebsd.dk> References: <6882.1215446754@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080707173102.L63144>