Re: pthread roadmap

[Neal H. Walfield]

> Right.  Neal, can you check in your pthread code into the Hurd CVS and
> continue maintaining it there?  Then we can cut a new Debian tar file and
> start compiling packages.

I will do it this weekend.  Well, perhaps Thursday: I have an exam and
a paper due on Wednesday so I do not have time to fool around with
this stuff at the moment.

> > 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.
> 
> Right.  I hope Neal can comment on this point.

Well, we can just ignore the pthread cancelation code if noone uses
it: there will be no cancelation if noone calls pthread_cancel.
Eventually, we will want to figure out how to merge the Hurd
cancelation semantics and the pthread cancelation semantics, however,
for now, I do not think that this is terribly important.

As for the current cancelation code, cthreads only interacts with the
libc signal code in hurd_condition_wait (libthreads/cancel-cond.c).
This can easily be reimplement to use the pthread primitives.


Another minor problem is stack size.  Right now, we have fixed size
stacks.  The default is 2MB which is far too large for Hurd servers,
however, the default of 64kb under cthreads is far too small for
applications.

> > 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.

I think is will be sufficient to start to bang on them with user space
applications.  (Not to mention that that requires significantly less
work.)  But, I certainly agree with what you have said.

> BTW, someone is already working on doing the transition, so another reason
> to do this (if everything works out ok) is that somebody else does it for
> us, which is the best reason I can think of ;)

I second that.