Re: pthread roadmap

[Roland McGrath]

I still have not read Neal's pthreads code, so I am just talking about the
general case assuming everything is as billed.  If this libpthread hooks
into libc the same way as cthreads does, and otherwise works with at least
the functionality of cthreads (which ain't much), then there is no reason
not to use it as the immediate transitional solution.  For user programs
it's a no-brainer--it's better than nothing.

For the Hurd servers, the requirements are different from normal programs
written for pthreads.  The really sticky bit is the Hurd cancellation
semantics, but that's mostly implemented in libc.  For an immediate
transition, we need a pthreads that doesn't use the POSIX cancellation
features at all (behaves like POSIX disabled cancellation), but works with
hurd_thread_cancel and hurd_check_cancel properly.  The really hard part is
the proper interaction of hurd_thread_cancel with interruptible RPCs, but
that is done in libc.  In pthreads you also need an equivalent of
hurd_condition_wait, and a normal pthread_cond_wait (if that's what
cthreads' condition_wait will translate to) that is NOT a cancellation
point for hurd_thread_cancel.  That is, everything to make pthreads provide
exactly the Hurd libthreads functionality by different names.

If we have that, then I see no reason not to proceed with the switchover.
The Hurd server code with pthreads+hurd-cancellation will look closer to
what it will eventually look like than what it looks like now does.  The
only reason not to switch is the first reason not to do anything: cthreads
is well-worn and hasn't surprised us in a long time, and the new code
always has the potential to make life more interesting in unplanned ways.
I probably won't audit the code thoroughly, but if Marcus and Neal run
pthreadsified Hurds and beat on them for a while and declare it good, I
will be satisfied.

This is a temporary transition solution, and for the Hurd servers per se I
don't think it much helps anything to do the conversion now rather than
only once later for the final pthreads implementation.  But if it helps
things like L4 work or whatever, then that is worthwhile if the cost is
low.  The conversion work that would be done now is just the first and
easiest part of what would have to be done later.  There is no cost to
doing it now, unless Neal's library has lots of bugs and the time-consuming
ones are in code that won't be reused for the final one.

As to the likely future for the integrated glibc pthreads, I won't say much
now.  It shouldn't be all that much work in the grand scheme on things.
But as I have yet to actually get my ass in gear, it would be disingenuous
to start estimating now when it might arrive at the various waystations.

It seems like the conversion to Neal's pthreads could be done quite quickly
and painlessly if all goes well.  So if you are motivated about it then we
might as well, even if it is only a short transition period.  Aside from
the packaging stuff, there is nothing in the Hurd work itself that would be
wasted work thrown away after the transition period.  OTOH this conversion
doesn't buy us anything anyone needs right now AFAIK--it's having pthreads
available for user programs that matters now, and it's the conversion for
the final thread library that will matter in the Hurd servers.  (If there
is L4 hacking that this matters to now, then that is something it buys us.)