Re: RFA: gdb/568, messy thread exits

[Jim Blandy <jimb at redhat dot com>]

Daniel Jacobowitz <drow@mvista.com> writes:
> I don't think so, but I don't have complete information.  For one
> thing, the next major LinuxThreads revision seems to have slipped
> beyond the next major glibc release; for another, given all the work
> Ingo Molnar's been putting in on minimal-overhead clone() and scalable
> scheduling for this new library, I doubt he'd advocate wedging multiple
> threads into a process.  But the development is not happening in
> public, so I don't really know.

<rumor>

If I followed the thread correctly, I think I've heard Uli say that
he's basically abandoned the M-on-N threads implementation, basically
because he can't get the support he wants from the kernel.  Uli and
the kernel people disagree on how far the kernel should go to support
pthreads.

Everyone agrees that glibc and Linux together ought to correctly
implement the pthreads interface.  Correctness isn't at issue.  But
they disagree on whether Linux should provide special support to make
pthreads more efficient.

Ingo's position is that people who really want speed should use the
non-portable kernel interfaces directly, and that people using
portable interfaces should expect less-than-optimal performance.
Providing optimal support for every random API some standards group
has invented will complicate the kernel far too much.  The groups
really working on performance (databases; web servers) will all use
the non-portable interfaces, and give good benchmarks on real-world
applications.

Uli's position is that most people will use the portable interfaces,
so (I may be filling in here) it benefits more people to improve their
performance.

</rumor>