Date: Tue, 8 Jul 2008 00:06:36 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Ken Smith <kensmith@cse.Buffalo.EDU> Cc: arch@freebsd.org, Sergey Babkin <babkin@verizon.net> Subject: Re: Proposal: a revoke() system call Message-ID: <20080708000132.K63144@fledge.watson.org> In-Reply-To: <1215457201.89956.11.camel@neo.cse.buffalo.edu> References: <48714866.906912CC@verizon.net> <20080707000313.P56885@fledge.watson.org> <1215457201.89956.11.camel@neo.cse.buffalo.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 7 Jul 2008, Ken Smith wrote: > On Mon, 2008-07-07 at 00:05 +0100, Robert Watson wrote: >> You could achieve something of the same end by opening /dev/null and then >> dup2()'ing to the file descriptor you want to revoke, perhaps? > > I might be missing something but isn't this what the deadfs vnodeops are > for? It's a little different, although similar. When a vnode is deadfs'd, such as after a call to revoke(2)'s historic implementation, all open file descriptors on the file are invalidated. I think that Sergey is suggesting semantics in which only the current file descriptor refering to the object is invalidated -- other independently acquired file descriptors in other processes would remain valid. BTW, this does show up one of the potential semantic conflicts in the proposed new revoke behavior: suppose a TCP connection is opened, and two processes have references to the file descriptor for the connection. One of those processes is multi-threaded, and has a blocking read(2) on the file descriptor in one thread, and calls close(2) from another thread. Is the proposal to cancel in-progress I/O's against the file descriptor even though the connection isn't closing due to the further reference to the same descriptor in another process? Solaris has a pretty complex infrastructure to support that sort of in-kernel cancellation -- the shutdown(2) behavior we have is fairly different in that it manipulates connection state to cancel outstanding I/O's, and would also affect the second process, rather than simply consumers on the one file descriptor. 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?20080708000132.K63144>