This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: LIBPTHREAD development step


Denis Vakatov wrote:
> 
> 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.
> 
The current inability of the kernel to identify threads and
connect them with their process also makes it impossible for
the kernel to handle, in an intellegent and intuitive way,
process resources.  In particular, POSIX timers are process
wide and the kernel, if it is to handle the timers, needs to
know which process the timer belongs to.  

Today POSIX timers are handled in glibc/linux threads, but
the high-res-timers work is implementing timers in the
kernel.  In an attempt to define the system call stubs for
POSIX timers for this effort, I found that the stubs depend
on the threads package using CLONE_THREAD.  The alternative
is VERY messy and high overhead.  The timers in this package
have a resolution of 1 micro second, so it makes little
sense to introduce high overhead "hacks" in glibc to get
around the lack of CLONE_THREAD.

Please reconsider your opposition to CLONE_THREAD.

George


> 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.
> >

-- 
George Anzinger   george@mvista.com
High-res-timers: 
http://sourceforge.net/projects/high-res-timers/
Preemption patch:
http://www.kernel.org/pub/linux/kernel/people/rml


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]