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/
This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:19 EST