On Thu, Oct 22, 2015 at 08:34:19AM +0200, casper....@oracle.com wrote: > > > >And I'm really curious about the things Solaris would do with dup2() there. > >Does it take into account the possibility of new accept() coming just as > >dup2() is trying to terminate the ongoing ones? Is there a window when > >descriptor-to-file lookups would fail? Looks like a race/deadlock country... > > Solaris does not "terminate" threads, instead it tells them that the > file descriptor information used is stale and wkae's up the thread.
Sorry, lousy wording - I meant "terminate syscall in another thread". Better yet, make that "what happens if new accept(newfd) comes while dup2() waits for affected syscalls in other threads to finish"? Assuming it does wait, that is... While we are at it, what's the relative order of record locks removal and switching the meaning of newfd? In our kernel it happens *after* the switchover (i.e. if another thread is waiting for a record lock held on any alias of newfd and we do dup2(oldfd, newfd), the waiter will not see the state with newfd still refering to what it used to; note that waiter might be using any descriptor refering to the file newfd used to refer to, so it won't be affected by the "wake those who had the meaning of their arguments change" side of things). -- 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
