Fwd: Re: RFC: Lightweight synchronization mechanism for gnumach v3

[Agustina Arzille]

-------- Original Message --------
Subject: Re: RFC: Lightweight synchronization mechanism for gnumach v3
Date: 2016-04-15 15:13
From: Agustina Arzille <avarzille@riseup.net>
To: Samuel Thibault <samuel.thibault@gnu.org>

On 2016-04-15 15:01, Samuel Thibault wrote:
> Agustina Arzille, on Fri 15 Apr 2016 14:59:11 -0300, wrote:
> > Great! Thanks a lot, Samuel! :3
> >
> > Coincidentally, my copyright assignment was just finished, so this 
> > came
> > just in time.
>
> Actually, I commited it *because* I also received the copyright
> assignment notification :)

Oh, right, that makes sense :P

> > Regarding the new libpthread: I can publish it with no problem, 
> > although
> > it's a standalone lib and not a glibc-add on yet, because I wanted to
> > test it well first.
>
> Ah, this is yet another libpthread?  We need to converge on one
> implementation.  There was also a proposal to just adapt nptl to Mach,
> which is probably possible now with gsync (the BSD guys told us they
> could do it quite easily).
>
> Samuel

Well, what I have right now is heavily based on nptl, but there are some 
things
that are different, mostly because implementing them in the Hurd would 
be very
awkward, difficult, or just downright impossible.

For example, nptl uses signals for thread cancellation, makes several
assumptions about the dynamic linker (specially regarding the main 
thread),
and has a lot of functionality that requires kernel features that 
gnumach
currently does not have.

On the other hand, the Hurd has different signal handling semantics, and 
its
setgid/setuid is very different from what's in Linux, so we can't just 
have
a carbon copy on nptl. Like you said, though, having 'gsync' made 
writing
this lib *far* easier than I first imagined.