On 2/3/06, Hans-Werner Hilse <[EMAIL PROTECTED]> wrote: > I can recommend NPTL for situations where threading really matters. And > it only speeds threading, so whether using it or not is a matter of > analyzing your application landscape...
I agree. Java applications in particular seem to benefit greatly from nptl. > > BTW, I don't suggest switching to NPTL either. If one starts a new > Gentoo installation, I think it would be a good idea to use NPTL right > from the start (and even try nptlonly). Switching from linuxthreads to > nptlonly brings some risks mentioned above. So a "emerge -e world" may > be a good idea in the case one goes down that road. NPTL is a drop-in replacement for pthreads, and is only a change in glibc (specifically, libpthread.so). In fact the vast majority of applications (even those that are multi-threaded) will never notice the difference between pthread and nptl. It seems only some older, binary only applications that depend on particular (unspecified and undocumented) behaviors of pthreads that have a problem. But the compatibility is now greatly improved, probably to nearly 100%. In fact, other than fire-eyes, _nobody_ has reported an nptl/nptlonly problem on this list recently, despite the fact that there are several people here (myself included) that use nptlonly. Plus, bugs.gentoo.org shows no current nptl-specific bugs. There are a few bugs still open regarding nptl, but the are more than 18-months old, with nobody able to duplicate them, and the original author having disappeared. In any case, emerge -e is definitely not necessary...merging just glibc (which you have to do to change the flags anyway) is sufficient. -Richard -- gentoo-user@gentoo.org mailing list