On Tuesday 12 December 2006 06:34, Arne H. Juul wrote:
This is exactly the sort of issue that should be solved by the
thread library / kernel threads implementation and not in every
threaded application that needs it, in my view.
It should not be done in new thread library, do you want a bloat
and error-prone thread library ? Instead if this semantic is really
necessary, it should be done in kernel.
Well, it depends on the alternatives.
If a clean kernel implementation is possible - yes please, of course.
If only a complex, error-prone kernel implementation is possible,
I would prefer to have the complexity in the thread library.
Hacking libthr or libpthread to do this for you is not
an option. They would then look like libc_r since all
fd's accesses would need to be wrapped. If this needs
to be done, it must be in the kernel.
It's also couldn't be entirely solved by fixing it in the
threads library. You could still have a non-threaded
application that waits on a read operation, but receives
a signal and closes the socket in the signal handler.