On 22/10/15 19:16, Al Viro wrote:
Don't you have to do that anyway, to do anything useful with the file?
Dirtying the cacheline that contains struct file itself is different, but
that's not per-descriptor.
Yes, true enough.
Usually it's per-process, but any thread could ask for a private instance
to work with (and then spawn more threads sharing that instance - or getting
independent copies).
[snip]
Thanks again for the info, interesting. Solaris also does things along
the same lines. In fact we recently extended posix_spawn so it could be
used by the JVM to create subprocesses without wholescale copying, and
Casper has done some optimisation work on posix_spawn as well.
I don't think that it's possible to claim that a non-atomic dup2()
is POSIX-compliant.
Except that it's in non-normative part of dup2(2), AFAICS. I certainly
agree that it would be a standard lawyering beyond reason, but "not
possible to claim" is too optimistic. Maybe I'm just more cynical...
Possibly so, and possibly justifiably so as well ;-)
ThreadA remains sat in accept on fd1 which is now a plain file, not
a socket.
No. accept() is not an operation on file descriptors; it's an operation on
file descriptions (pardon for use of that terminology). They are specified
by passing descriptors, but there's a hell of a difference between e.g.
dup() or fcntl(,F_SETFD,) (operations on descriptors) and read() or lseek()
(operations on descriptions).
Lookups are done once per syscall; the only exception is F_SETFL{,W}, where
we recheck that descriptor is refering to the same thing before granting
the lock.
Yes, but if you believe that dup2() requires an implicit close() within
it and that dup2() has to be atomic then expecting that other threads
waiting on the same fd in accept() will get a notification seems
reasonable enough.
Again, POSIX is still underspecifying the semantics of shared descriptor
tables; back when the bulk of it had been written there had been no way
to have a descriptor -> description mapping changed under a syscall by
action of another thread. Hell, they still hadn't picked on some things
that happened in early 80s, let alone early-to-mid 90s...
That's indisputably true - much of the POSIX behaviour predates threads
and it shows, quite badly, in some places.
Linux and Solaris happen to cover these gaps differently; FreeBSD and
OpenBSD are probably closer to Linux variant, NetBSD - to Solaris one.
Yes, true enough.
--
Alan Burlison
--
--
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
