Date: Mon, 7 Jul 2008 00:05:29 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Sergey Babkin <babkin@verizon.net> Cc: arch@freebsd.org Subject: Re: Proposal: a revoke() system call Message-ID: <20080707000313.P56885@fledge.watson.org> In-Reply-To: <48714866.906912CC@verizon.net> References: <48714866.906912CC@verizon.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 6 Jul 2008, Sergey Babkin wrote: > int revoke(int fd, int flags) Seems like that conflicts with our existing revoke(2) system call. 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? Right now there's a known issue that calling close(2) on a socket from one thread doesn't interrupt a socket in a blocking I/O call from another thread -- you first have to call shutdown(2), and then close(2). This has caused problems for Java in the past, but I'm not sure that it's really a bug given that it's not unreasonable behavior not rejected by the spec :-). Robert N M Watson Computer Laboratory University of Cambridge > > Revoke a file desriptor from this proces. For all practical > purposes, it's equivalent to close(), except that the descriptor > (fd) is not freed. Any further calls (except close()) on this fd > would return an error. Close() would free the file descriptor > as usual. If any calls were in progress sleeping (such as read() > waiting for data), they would be interrupted and return an error. > > Flags could contain a bitmap that would modify the meaning of the > call. I can think of at least one such modification: REVOKE_EOF, > that if set, would make any further read() calls return 0 (EOF > indication) instead of an error. > > Rationale: > > In the multithreaded programs often multiple threads work with the > same file descriptor. A particularly typical situation is a reader > thread and a writer thread. The reader thread calls read(), gets > blocked until it gets more data, then processes the data and > continues the loop. Another example of a "reader thread" would be > the main thread of a daemon that accepts the incoming connections > and starts new per-connection threads. > > If the application decides that it wants to close this file > descriptor abruptly, getting the reader thread to wake up and exit > is not easy. It's fraught with synchronisation issues. > Things get even more complicated if there are multiple layers > of library wrappers. > > The proposed system call makes it easy to pretend that the file > descriptor has experienced an error (or that a socket connection > has been closed by the other side). The library layers should be > already able to handle errors, so the problem would be solved > transparently for them. For sockets a similar > functionality can already be achieved with shutdown(fd, SHUT_RDWR). > But it works only for connected sockets, not for other file types > nor sockets runnig accept(). A new system call would apply it > to all the kinds of file descriptors. Another option is > to extend the shutdown() call to the non-socket file descriptors. > > Any comments? Would anyone mind if I implement it? > > -SB > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080707000313.P56885>