Re: [C++] Re: LIBPTHREAD development step

[Anton Lavrentiev <lavr at ncbi dot nlm dot nih dot gov>]

Ulrich Drepper wrote:
> 
> Anton Lavrentiev wrote:
> >>Note that for glibc 2.2 we only accept bug fixes, these kind of
> >>patches are more appropriate for the glibc 2.3 branch but Ulrich is
> >>also working on similar issues, so your patch might conflict with his
> >>work.
> 
> I'm not going to accept anything but trivial changes for the thread
> library.  Live with the defficiencies.  A change such like the proposed
> will only cause problems without any major benefits.
> 

Okay, I got your point. However, let me disagree with that there are no major benefits.

First of all, having threads managed by the kernel (which in current pthread
implementation is not even aware of the fact that all those clone()'d processes
are in fact threads in the program, not just forked copies) will benefit from the
threads been killed should the "parent" unexpectedly die. This is very important
to have pthread-based programs to work cleanly. Presently, if the parent dies the way
not foreseen by the library, the orphaned threads continue to run and clobber things,
like holding system resources and thus preventing from process restart (like if
holding a semaphore or lock). We regularly see this behavior in our server
programs, which might die due to network-related problems (disconnects),
timeouts, etc. In most of the cases, the restart is possible, but there are
still bad situations where a human hand is still needed, due to the
kernel unawareness. Why would glibc be worse than Solaris's lib in the way
it can easily handle this? And yet with all means available. To live with
defficiencies as suggested in more like Microsoft's way, not GNU's,
don't you think so?

Secondly, process accounting is simply not possible because you cannot
sort out real threads and real processes. You never know whether a given
process a full-weight process or LWP, sharing most of its resources with its
other siblings. We tried to employ process maps for that, it works only partially
as map extraction transations are not inter-locked, and may change while
retrieved for comparison. Having a TGID is the only way to make the
accounting accurate.

Thirdly, the proposed change does not in fact change anything radical in
the library per se, and it is unclear what problems it might create then.
The only thing it changes is the way the kernel sees the threads.

It was mentioned that the suggested patches are more for GLIBC 2.3 than
the current release. Where should I submit them to be considered for
the next major release, at least?

Thanks.