Date: Tue, 8 Jul 2008 00:23:01 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Sergey Babkin <babkin@verizon.net> Cc: arch@FreeBSD.ORG, David Schultz <das@FreeBSD.ORG>, Poul-Henning Kamp <phk@phk.freebsd.dk> Subject: Re: Re: Re: Proposal: a revoke() system call Message-ID: <20080708001929.E63144@fledge.watson.org> In-Reply-To: <9484951.340521215467447990.JavaMail.root@vms126.mailsrvcs.net> References: <9484951.340521215467447990.JavaMail.root@vms126.mailsrvcs.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080708001929.E63144>