Thread (138 messages) 138 messages, 9 authors, 2015-11-06

Re: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect for sockets in accept(3)

From: Al Viro <viro@ZenIV.linux.org.uk>
Date: 2015-10-29 17:07:56

On Thu, Oct 29, 2015 at 04:15:33PM +0000, Alan Burlison wrote:
There was an attempt to interpret POSIX that way, with which I still
disagree. If a FD is closed or reassigned then any current pending
operations on it should be terminated.
Could the esteemed sir possibly be ars^H^H^Hprevailed upon to quote the exact
place in POSIX that requires such behaviour?

This is getting ridiculous - if we are talking about POSIX-mandated behaviour
of close(), please show where is it mandated.  Using close(2) on a descriptor
that might be used by other threads is a bloody bad design in userland code -
I think everyone in this thread agrees on that.  Making that a recommended way
to do _anything_ is nuts.

Now, no userland code, however lousy it might be, should be able to screw
the system.  But that isn't the issue - our variant is providing that just
fine.

BTW, "cancel accept(2) because sending a signal is hard" is bogus anyway -
a thread in accept(3) just about to enter the kernel would get buggered
if another thread closes that descriptor and the third one does socket(2).
_IF_ you are doing that kind of "close a descriptor under other threads"
thing, you need to inform the potentially affected threads anyway, and
you'd better not rely on them being currently in kernel mode.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help