Andrew Doran <ad@netbsd.org> wrote:
> A while back rmind@ suggested changing changing clone() to create new LWPs
> within the same process (instead of creating a new process), and on the face
> of it that makes a lot of sense. It would remove some the complexity around
> sharing those data structures.

As I understand, your intention is to use an LWP for any clone() call. As
Bill already asked - do we really need all the complexity? In general clone()
call is an extended fork(), is it necessary to change this behaviour?

My main suggestion was for clone() extensions used by NPTL [1]. With the
specific flags, clone() call is used to create a thread (not a process).
Currently, our Linux emulation code creates the processes instead of threads,
and here it would be great to see the usage of LWPs.

> That would create problems for threaded applications that use kill() to post
> signals to other threads within the same process (well, to other processes
> really). I think we could work around that by checking to see if a process
> has created a new thread using clone(), and if it has, then allocate a PID
> from the proc table for each thread, but with no associated process. The PID
> could then be mapped onto an LWP in the process for sending signals.

AFAIK, the behaviour of NPTL threads (created with clone() call) is more or
less same as our pthreads (LWPs, actually). As they share the same PID, the
signals are handled by all threads (except there are some internal signal
codes). But well, I am not sure if this have not changed in these days..

All we need, I think, is a clone() behaviour as fork1() with one flags, and
as newlwp() with another ones :)

[1]. http://people.redhat.com/drepper/nptl-design.pdf

-- 
Best regards,
Mindaugas
www.NetBSD.org