Messages in this thread |  | | From | kuznet@ms2 ... | Subject | Re: [PATCH] thread wakeup fix for 2.4.0-test7 | Date | Sun, 27 Aug 2000 21:42:04 +0400 (MSK DST) |
| |
Hello!
> About the only case when program's behaviour is _not_ undefined with such > scenario is the following: > > thread A: > poll() on array including descriptor n > thread B: > close(n);do something that leads to event on file that used to be > refered by n
"Something" is already done. It is close() itself. And this is exactly the thing, which does not work in Linux.
> everything else: > make damn sure that no events on that file will happen until B > will do its thing. > > Subtle, britlle and nonportable.
It is nonportable _only_ to Linux (and to old freebsds btw, its user level pthread library had the same bug). 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.
Indeed, the trick looks dirty from unix viewpoint, but it is valid, when "B" is master thread, controlling state machine and timeouts and "A"s are pure service threads. I.e. usual model in MT programming.
Alexey - 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/
|  |