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

[Doug R. <df...@nl...>]

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.

> 
> > It was an interesting exercise putting together a pthread proxylwp
> > implementation but its certainly not the right solution for some
> > systems. For example on FreeBSD 4.x there is no decent support for
> > kernel threads and the userland threading library relies on intercepting
> > all the blocking syscalls and using poll(2) in the thread scheduler to
> > attempt to switch threads when they would block.
> 
> Is that because FreeBSD 4.x doesn't have any kind of kernel-level
> shared-address-space thread thing?  Is it that the poll trick works for
> looking at syscalls which block on FDs, but doesn't really help for
> other types of blocking syscall?

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.

> 
> How important is FreeBSD 4.x as a target?

I'm not quite sure. I might have some people who want FreeBSD 4.x
support for their own use but they probably don't need complete support
(probably not full pthreads support for instance). I'm still waiting to
hear from them.