Re: pthreads

[Neal H. Walfield]

> Cool work.  I am missing a couple of guidelines where to put what, though. 
> It seems there is a hurd.diff to make it part of the Hurd, but there is also
> a pthread/pthread.patch that touches glibc.

pthread.patch is Mark's patch to integrate pthreads with glibc. I have
not updated it.

> I can not see a full cthread wrapper in there that would allow to compile
> the Hurd using cthreads on L4.  Do you plan to add that?

No.  The cthreads wrapper supplies exactly what glibc depends
on--nothing more.  Both libthreads and libpthread can exist at the
same time (just not in the same process), as such we can migrate the
Hurd to pthreads at our own pace while other applications can
immediately benefit from pthreads.

> It seems we have now a strategy to put pthread support into the
> Hurd.  Neal's package can add pthreads to the Hurd source without touching
> glibc, and applications will just work.  The Hurd itself would still use
> cthreads, and glibc would not need to be changed (as the few callbacks it
> has into the thread package are provided by pthread).
> 
> This would allow us to develop the pthread package witout directly worrying
> xabout glibc, and put off some prssure (many Debian packages require
> pthread) so integration into glibc can happen at its own pace.
> 
> If I have understood all of the above correctly, is that a viable
> plan?

This is indeed the plan.  The only problem that I foresee is that the
binary interface might change as the rest of the pthreads interface is
filled in (for instance, adding fields to different structures).

Thanks.