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

Reply via email to