int revoke(int fd, int flags)

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