|Sergey Babkin||Jul 6, 2008 10:30 pm|
|Robert Watson||Jul 6, 2008 11:05 pm|
|Poul-Henning Kamp||Jul 7, 2008 7:50 am|
|Sergey Babkin||Jul 7, 2008 3:05 pm|
|Sergey Babkin||Jul 7, 2008 3:12 pm|
|Robert Watson||Jul 7, 2008 3:29 pm|
|Coleman Kane||Jul 7, 2008 3:39 pm|
|Poul-Henning Kamp||Jul 7, 2008 4:03 pm|
|Poul-Henning Kamp||Jul 7, 2008 4:05 pm|
|Robert Watson||Jul 7, 2008 4:33 pm|
|Sergey Babkin||Jul 7, 2008 5:28 pm|
|Sergey Babkin||Jul 7, 2008 5:32 pm|
|Sergey Babkin||Jul 7, 2008 6:49 pm|
|David Schultz||Jul 7, 2008 6:52 pm|
|Ken Smith||Jul 7, 2008 7:32 pm|
|Poul-Henning Kamp||Jul 7, 2008 7:55 pm|
|Bruce Evans||Jul 7, 2008 8:03 pm|
|Sergey Babkin||Jul 7, 2008 9:50 pm|
|Sergey Babkin||Jul 7, 2008 9:56 pm|
|Robert Watson||Jul 7, 2008 11:06 pm|
|Robert Watson||Jul 7, 2008 11:15 pm|
|Robert Watson||Jul 7, 2008 11:22 pm|
|Poul-Henning Kamp||Jul 8, 2008 6:09 am|
|Dag-Erling Smørgrav||Jul 8, 2008 11:16 am|
|Sergey Babkin||Jul 8, 2008 12:27 pm|
|Sergey Babkin||Jul 8, 2008 2:45 pm|
|Robert Watson||Jul 8, 2008 3:26 pm|
|Ed Schouten||Jul 8, 2008 3:36 pm|
|David Schultz||Jul 8, 2008 4:46 pm|
|Robert Watson||Jul 8, 2008 4:54 pm|
|John Baldwin||Jul 10, 2008 2:24 am|
|Subject:||Proposal: a revoke() system call|
|From:||Robert Watson (rwat...@FreeBSD.org)|
|Date:||Jul 6, 2008 11:05:13 pm|
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.
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?
_______________________________________________ free...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arch To unsubscribe, send any mail to "free...@freebsd.org"