confirmed working NPTL revision?

[Rob Landley]

On Tuesday 16 September 2008 02:48:49 Matthieu CASTET wrote:
> Hi,
>
> Rob Landley a écrit :
> >> IIRC
> >> there have been some issues in the past... so, unless we are totally
> >> sure, we need to keep the working/stable and old linuxthreads.old.
> >
> > No, what we do is we keep the 0.9.29 tarball around and if people have
> > bugs trying to use 0.9.30 they _report_ them to us.  If they want to use
> > the old threading code, they can use the old version of the library.  If
> > they want the new features, then they help us find (and fix) the new
> > bugs.
>
> You mean adding in the 0.9.30 untested code ?

There are currently two threading implementations in -svn, just as there were 
two in 0.9.29 and in 0.9.28 and for a few releases before that.

Look in the "General Library Settings" menu, under threading support 
there's "Use the older (stable) version of linuxthreads".   The config symbol 
is LINUXTHREADS_OLD.

This has nothing to do with NPTL, this has to do with using an obsolete 
version of the old Linuxthreads package, or using a newer version of the 
linuxthreads package.

There's no reason to have two versions of _linuxthreads_, since NPTL will in 
theory eventually obsolete _both_ of them.  Either we should say "the newer 
one failed, remove it", or say "the newer one works, remove the older one".  
I've had reports of the newer one working, so I'm inclined to remove the one 
that's _labeled_ OLD.

> Do you know if linuxthreads pass some thread regression tests (glibc
> one, ltp, ...) ?

Nope.  Would anyone like to test it?

I've got a smoke test, but it doesn't look for strange edge cases and doesn't 
look at performance or size at all.

> >> Remeber that, even when merged, NPTL is available only for 3 archs at
> >> the time being.
> >
> > Who said anything about NPTL?  Right now, in 0.9.29, there's
> > LINUXTHREADS_OLD and there's a second implementation of Linuxthreads that
> > most people haven't been testing because they're still on
> > LINUXTHREADS_OLD.  There's not much point in having two of these right
> > now, and adding NPTL would make _three_. I'd like to keep it to no more
> > than two, which means I need to yank one before NPTL goes in.
>
> I remember than 1 year ago, developers agree to drop LINUXTHREADS,
> because work should be done on nptl instead trying to fix LINUXTHREADS. [1]

Good for them.  More than 1 year ago the 0.9.30 release was imminent.  It 
didn't happen.  Yay NPTL branch, hopefully I'll live to see it.

> And I agree with that. If nptl merge happen soon there no point to do
> some extra work on LINUXTHREADS.

I'm not talking about extra work, I'm saying there are two redundant 
implementations and one of them should go.

>
> Matthieu
>
> PS : if only companies "selling" uclibc could hire some developers to
> improve the mainstream version ...

Yes and no: my understanding is that half the reason NPTL is in the state it's 
in was that sjhill refused to release his code until he got paid for it, by 
which point we had three competing implementations (but Erik had already 
promised sjhill his would go in first)...

Hiring developers is nice, but it's not necessarily _simple_.

> [1] nptl is really missing on some arch to get faster thread switch,
> some mutex with prio inversion, ...

*shrug*

Rob