Skip site navigation (1)Skip section navigation (2)
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>