Re: [Valgrind-developers] Re: source tree rearrangement, part 2

[Jeremy F. <je...@go...>]

On Sat, 2004-01-17 at 01:50, Doug Rabson wrote:
> On Sat, 2004-01-17 at 01:00, Jeremy Fitzhardinge wrote:
> > On Fri, 2004-01-16 at 01:51, Doug Rabson wrote:
> > > This happens automatically in the FreeBSD kernel. When a thread blocks
> > > in the kernel, an upcall to the userland thread scheduler happens and it
> > > switches to the next runnable thread.
> > 
> > Ah, OK.  That sounds like an interesting thing to virtualize when we
> > move to a threading model in which we expose virtual kernel interfaces
> > rather than just pthreads.
> 
> That might be quite interesting indeed. It is possible that I might be
> able to get the kernel threading authors involved if necessary though
> since this stuff is fairly recent and is still being actively
> maintained.

There's a tension between how we want to implement Valgrind and the
kinds of client programs we want to support.  For Valgrind internally,
we'd like to use the most portable code and interfaces, so pthreads
rather than clone.  But we want to support all the clients, including
those which use clone/rfork/upcalls directly. 

This means we need to do some things near the kernel interface to
virtualize all those things.  For Linux with clone, signals are the only
real problem, and only in 2.4.  Upcalls sound tricky; I don't know how
they work (any docs pointers?), but it seems that if the kernel does an
upcall, we need to intercept it, decide whether it is aimed at our
libpthread or at the client, and do the appropriate demultiplexing.

Given the large number of ways in which libpthread can be possibly
implemented, it means that using libpthread for Valgrind itself doesn't
necessarily give us any portability gains, because we still need to deal
with the raw kernel interface on the client's behalf.  

The question is whether using libpthread is a net gain or loss of
portability/complexity, and the answer isn't obviously clear to me.

Anyway, all the more reason to do a FreeBSD port, from my perspective.

> There is a shared-address-space fork which I used to get proxylwp
> working minimally on 4.x. I think the main problem with it as far as
> pthreads goes might be the signal routing thing that linuxthreads has -
> in fact there is a port of linuxthreads. The base system pthreads
> implementation is purely user-space threading.

OK; what are rfork's signal semantics?  Is it simply that signals arrive
at the process they're aimed at, with no shared signal state?  Does the
existing signal router in vg_signals.c cope with this correctly?

	J