On Sun, 27 Aug 2000 kuznet@ms2.inr.ac.ru wrote:
> > Subtle, britlle and nonportable.
>
> It is nonportable _only_ to Linux (and to old freebsds btw,
> its user level pthread library had the same bug).
Huh?
<doing cvs update just in case>
<reading sys_generic.c::read() and sys_generic.c::dofileread()>
Nope, world didn't change - read(9) does getfp(9) [== our fget(9)] and
then calls dofileread(9). The former returns the same on all dup()-created
copies of descriptor, the latter doesn't use fd at all unless you build
with KTRACE. Even if you do, the call that might, in principle, depend on
fd is done after fo_read(9).
_If_ somebody had changed FreeBSD so that close() on dup()'d descriptor
aborts read() on the original - he needs severe LARTing. I'm not on a
-CURRENT box right now, so I can't check it immediately, but you bet that
if it really does that idiocy it's going to be a send-pr time. Big way.
And AFAICS the idiocy above is the only way it can do what you've
described - it doesn't distinguish the dup()'d descriptors until the very
end of operation, way past any waiting for incoming data.
> This is de facto standard programming trick in pure MT programs.
> It works in solaris and dux. Its direct analogue works in nt and macos x.
> I have about dozen of bug reports blaming on this linux feature.
> Actually, people who used it are in big troubles because absence
> of possibility to shutdown thread sleeping in read/write/connect/poll
> forces to add to programs new logic, required only for linux.
And *BSD, unless they are using some userland wrappers around the read(2).
Which may be the case, but then I don't see where it becomes a kernel
problem on our end of things.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:19 EST