Proposal: a revoke() system call

[Robert Watson]

On Mon, 7 Jul 2008, Sergey Babkin wrote:

>> Well, fixing this is easy -- instead of holding a reference to the file 
>> descriptor over the system call, hold a reference to the socket.  The 
>> problem with that is that it creates a lot more contention on the socket 
>> locks when the reference count is dropped, not to mention more locking 
>> operations.  This can be fixed but requires quite a lot of work, whereas 
>> this rather minor semantic issue is a non-problem in practice.  I do have 
>> dealing with this
>
> I can't comment much without actually looking at the code, but why would the 
> contention on close() be such an issue? Close() is not called that often, 
> compared for example to read(), so there should not be much contention to 
> start with. And why not just call the shutdown() logic from inside close() 
> implementation?

This is a fairly complex issue, and one that doesn't lend itself to in-depth 
discussion without first looking at the code.  To direct your reading, I 
recommend starting with the socket reference model -- you can find a 
high-level summary in the comments at the head of uipc_socket.c, and the 
comments on sofree(9).  The question you're getting at indirectly has to do 
with the differences between fdrop(9), which drops a reference to a file 
descriptor, and fputsock(9), which drops a reference to a socket.  You'll also 
find it useful to do a bit of reading regarding the difference between 
close(2), which releases a reference to a file descriptor from userspace, and 
fo_close(9), which is invoked in-kernel when the last reference to a file 
descriptor goes away.

Robert N M Watson
Computer Laboratory
University of Cambridge