Re: LIBPTHREAD development step

[Denis Vakatov <vakatov at ncbi dot nlm dot nih dot gov>]

Dear Ulrich,

As you won't do it (by whatever reasons), can you please recommend who
should we contact to get the fix through.


Here is the rationale:
----------------------

This is an ugly bug, and we do need it fixed -- both to implement
effective load-balancing, and to avoid system mess-ups.

It's not a one-user concern (or caprise ;-).
Our organization serves millions of users daily (500 hits/sec on our
Web servers) in the medical and biotech community.

Regards,
Denis


-----------------------------------------------------------------------------
> Date: Tue, 03 Sep 2002 15:20:30 -0400
> From: Anton Lavrentiev <lavr@ncbi.nlm.nih.gov>
> CC: libc-alpha@sources.redhat.com, vakatov@ncbi.nlm.nih.gov,
>    domrach@ncbi.nlm.nih.gov, Andreas Jaeger <aj@suse.de>
> 
> Ulrich Drepper wrote:
> > 
> > 
> > Anton Lavrentiev wrote:
> > 
> > > Okay, I got your point. However, let me disagree with that there are no major benefits.
> > 
> > There are no major benefits doing this in libpthread.  If you want one
> > PID overload getpid().
> > 
> 
> The issue here was not in getting one PID but in having a multi-threaded
> application that lives as a single entity, not as a set of independent
> processes. And in having a means to determine which process in the system
> is a part of such an entity, and which is not.
> 
> >  > To live with defficiencies as suggested in more like Microsoft's way,
> >  > not GNU's, don't you think so?
> > 
> > No, it's not.  It means that I have no intention whatsoever to invest
> > any more time in this code.
> > 
> 
> Fair enough.
> 


-----------------------------------------------------------------------------
> Date: Tue, 03 Sep 2002 14:50:27 -0400
> From: Anton Lavrentiev <lavr@ncbi.nlm.nih.gov>
> Organization: NCBI NIH
> X-Accept-Language: en, ru
> CC: vakatov@ncbi.nlm.nih.gov, domrach@ncbi.nlm.nih.gov,
>    Andreas Jaeger <aj@suse.de>
> 
> 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.
>