-------- Original Message --------
Subject: Re: RFC: Lightweight synchronization mechanism for gnumach v3
Date: 2016-04-15 15:13
From: Agustina Arzille <avarzi...@riseup.net>
To: Samuel Thibault <samuel.thiba...@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.
