On Wed, Oct 21, 2015 at 03:38:51PM +0100, Alan Burlison wrote: > On 21/10/2015 04:49, Al Viro wrote: > >BTW, for real fun, consider this: > >7) > >// fd is a socket > >fd2 = dup(fd); > >in thread A: accept(fd); > >in thread B: accept(fd); > >in thread C: accept(fd2); > >in thread D: close(fd); > > > >Which threads (if any), should get hit where it hurts? > > A & B should return from the accept with an error. C should continue. Which > is what happens on Solaris.
So, I'm coming late to this discussion and I don't have the original context; however, to me this cited behavior seems undesirable and if I ran across it in the wild I would probably describe it as a bug. System call processing for operations on files involves translating a file descriptor (a number) into an open-file object (or "file description"), struct file in BSD and I think also in Linux. The actual system call logic operates on the open-file object, so once the translation happens application monkeyshines involving file descriptor numbers should have no effect on calls in progress. Other behavior would violate the principle of least surprise, as this basic architecture predates POSIX. The behavior Al Viro found in NetBSD's dup2 is a bug. System calls are supposed to be atomic, regardless of what POSIX might or might not say. I did not write that code but I'll pass the report on to those who did. -- David A. Holland dholl...@netbsd.org -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
