Proposal: a revoke() system call

[Robert Watson]

On Mon, 7 Jul 2008, Poul-Henning Kamp wrote:

> In message <20080707162733.V63144 at fledge.watson.org>, Robert Watson writes:
>
>>>> 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
>>>
>>> That's a great idea. I haven't thought about it. It should do everything.
>>
>> Right, and possibly this means that no additional kernel support is 
>> required -- we just make it a libc or libutil interface.
>
> I can't see how that could possibly work...
>
> If you do a dup2(), the original fd is closed, and that still does not 
> release all threads that may be sleeing on it in device drivers.

I see interrupting current consumers as a separable issue from invalidating 
the file descriptor for future users.  I'm not convinced there's a good 
general solution for interrupting current consumers of a file descriptor -- we 
can improve the semantics for a few objects (i.e., sockets) if required, but 
I'm not sure it generalizes well.  For sockets, generally speaking, calling 
shutdown(2) is the approved way to initiate a disconnect, which will lead to 
other consumers being kicked out of operations on the file descriptor, rather 
than close(2), which in general doesn't initiate a disconnect because it's a 
reference count operation on the underlying object.

Robert N M Watson
Computer Laboratory
University of Cambridge