Messages in this thread |  | | Date | Sun, 27 Aug 2000 14:28:08 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: [PATCH] thread wakeup fix for 2.4.0-test7 |
| |
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/
|  |