headers
Roland McGrath | 1 Aug 2002 12:03

Re: pthreads

> Roland, you once said that you wanted a complete rewrite of the Hurd
> signal code currently in glibc.  Could you share the design with me
> and whether you think I should implement that or just port the current
> code in glibc for now?

I think the rewriting that should be done is pretty much orthogonal to an
L4 port.  

> As is quite obvious, the Hurd uses cthreads.  Should I try to maintain
> a cthreads compatibility layer in my pthread implementation (this is
> the way that Mark was leaning)?  An alternative would be to just
> convert the current code to use pthread unconditionally.  If we did
> this, would it be better to provide a simple pthreads layer on top of
> cthreads or to just ignore the incompatibility?

We won't merge changes to the hurd code until we have pthreads on Mach too.
A cthreads compatibility layer on your pthreads library should be a few
trivial macros, modulo hurd_check_cancel, which I think you should just
implement instead of the pthreads cancellation semantics for the time being
to make things simpler.
Permalink | Reply | 9 comments |
headers
Neal H. Walfield | 1 Aug 2002 12:25
Favicon

Re: pthreads

> > Roland, you once said that you wanted a complete rewrite of the Hurd
> > signal code currently in glibc.  Could you share the design with me
> > and whether you think I should implement that or just port the current
> > code in glibc for now?
> 
> I think the rewriting that should be done is pretty much orthogonal to an
> L4 port.  

Certainly, however, as using the current infrastructure will require
more than a few changes, I thought it might make sense to just rewrite
it right now.

> We won't merge changes to the hurd code until we have pthreads on Mach too.
> A cthreads compatibility layer on your pthreads library should be a few
> trivial macros, modulo hurd_check_cancel, which I think you should just
> implement instead of the pthreads cancellation semantics for the time being
> to make things simpler.

I have already implemented the pthread cancelation interfaces and
started to adjust parts of the Hurd to use it.  I am dubious of
benefits of not going directly to pthreads.
Permalink | Reply | 4 comments |
headers
Roland McGrath | 1 Aug 2002 12:26

Re: pthreads

> Certainly, however, as using the current infrastructure will require
> more than a few changes, I thought it might make sense to just rewrite
> it right now.

Not really.  I don't think your changes for L4 will need to be that extensive.

> I have already implemented the pthread cancelation interfaces and
> started to adjust parts of the Hurd to use it.  I am dubious of
> benefits of not going directly to pthreads.

The sole benefit is using the hurd sources as they are now, because I am
pretty sure I don't want to make any changes anything like now.
Permalink | Reply | 3 comments |
headers
Marcus Brinkmann | 1 Aug 2002 18:16
Picon
Favicon

Re: pthreads

On Thu, Aug 01, 2002 at 06:26:07AM -0400, Roland McGrath wrote:
> > Certainly, however, as using the current infrastructure will require
> > more than a few changes, I thought it might make sense to just rewrite
> > it right now.
> 
> Not really.  I don't think your changes for L4 will need to be that extensive.

The changes with pthreads and the IPC model are independent, but they are
not just search and replace.  Many changes are of syntactical nature, but
some are not, and there are also a couple of changes that are not just
search and replace but touch a lot of code. 

In general, the goal is not to provide a full Mach emulation on L4, but to
tighten the requirements, in particular in the IPC structure.  The reason
is not really to accomodate the design of L4, but to make the Hurd more
flexible, faster and more robust on platforms which allow that (Mach
doesn't ;).  It might not be strictly necessary to change as much in the
Hurd to get it running on L4, but by reconsidering some of the assumptions
in the Hurd we can get huge benefits, and it's a good time to do it along
with the port, instead of afterwards.

I have followed Neal's work on L4 from the early beginning as good as I
could, and I think he is on the right track with those changes.  It's too
early though to say if we can really keep the same Hurd code base for Mach
and L4 feasibly, in particular if it is worth the effort to write the
wrappers around Mach that would be needed to do that.

I have not given any details here, Neal will do this as soon as he feels
comfortable about that, and you probably don't have the time to dig into
them right now anyway.  Some details are already available on the l4hurd
(Continue reading)

Permalink | Reply | 2 comments |
headers
Roland McGrath | 1 Aug 2002 23:27
Picon

Re: pthreads

You would have a lot more sympathy and cooperation with me if I'd been kept
abreast of what implementation decisions you've made and what kinds of code
changes you intend.
Permalink | Reply | 1 comment |
headers
Neal H. Walfield | 2 Aug 2002 00:11
Favicon

Re: pthreads

> You would have a lot more sympathy and cooperation with me if I'd been kept
> abreast of what implementation decisions you've made and what kinds of code
> changes you intend.

Well, at the end of May in message
20020529095900.557D71BA15 <at> perdition.linnaean.org, I asked about the
Hurd port to Fluke.  You said a few things and concluded with:

    I can get into more detail when I feel like typing more.

And yet you never did.  It is this complete lack of reaction to any of
the emails that I have sent in the last months that I have felt little
need to seek feedback from this list.
Permalink | Reply | 0 comments |
headers
Neal H. Walfield | 4 Aug 2002 21:07
Favicon

Re: pthreads

> We won't merge changes to the hurd code until we have pthreads on
> Mach too.

You win.  I sat down this afternoon and ported my implementation to
Mach.  You can find it here [1].  There are still several problem to
be worked out and code to be cleaned up, however, I would appreciate
it if you could take a look and criticize what I have done so far.
The main problem that I currently fighting with is lockfile.c: it just
does not want to compile for some reason.

To compile, just extract the tarball in the base of a Hurd tree, run
`patch -p0 < libpthread/hurd.diff', configure and `make pthread'.

Thanks.

[1] walfield.org/pub/people/neal/hurd/libpthread
Permalink | Reply | 3 comments |
headers
Marcus Brinkmann | 7 Aug 2002 14:39
Picon
Favicon

Re: pthreads

On Sun, Aug 04, 2002 at 09:07:49PM +0200, Neal H. Walfield wrote:
> > We won't merge changes to the hurd code until we have pthreads on
> > Mach too.
> 
> You win.  I sat down this afternoon and ported my implementation to
> Mach.  You can find it here [1].

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.

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?

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?

Thanks,
Marcus

--

--
(Continue reading)

Permalink | Reply | 2 comments |
headers
Neal H. Walfield | 7 Aug 2002 15:04
Favicon

Re: pthreads

> 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
(Continue reading)

Permalink | Reply | 1 comment |
headers
Marcus Brinkmann | 7 Aug 2002 15:17
Picon
Favicon

Re: pthreads

On Wed, Aug 07, 2002 at 03:04:06PM +0200, Neal H. Walfield wrote:
> 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).

well, as long as it is not integrated into glibc, we can just bump up
soname as often as we want, and make one pthreadX package for each version.
OTOH, as long as it is not integrated into glibc, it probably makes sense
to just have a lot of padding bytes in the structures for future extension
so we don't need to change the ABI too often.  So there is certainly a
solution to that, although it is inconvenient.

If we just keep the pthread stuff local to the Hurd package for now, then we
don't need to do any such stuff.

Thanks,
Marcus

--

-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    marcus <at> gnu.org
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
Marcus.Brinkmann <at> ruhr-uni-bochum.de
http://www.marcus-brinkmann.de/
Permalink | Reply | 0 comments |

Gmane