From owner-freebsd-arch@FreeBSD.ORG Sun Jul 6 23:05:30 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 F41061065680 for ; Sun, 6 Jul 2008 23:05:29 +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 C8C248FC36 for ; Sun, 6 Jul 2008 23:05:29 +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 54DCB46C64; Sun, 6 Jul 2008 19:05:29 -0400 (EDT) Date: Mon, 7 Jul 2008 00:05:29 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Sergey Babkin In-Reply-To: <48714866.906912CC@verizon.net> Message-ID: <20080707000313.P56885@fledge.watson.org> References: <48714866.906912CC@verizon.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org 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: Sun, 06 Jul 2008 23:05:30 -0000 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" >