Subject: Re: clone()
To: Andrew Doran <email@example.com>
From: Bill Stouder-Studenmund <firstname.lastname@example.org>
Date: 09/15/2007 19:51:31
Content-Type: text/plain; charset=us-ascii
On Sun, Sep 16, 2007 at 02:47:59AM +0100, Andrew Doran wrote:
> The clone() syscall means that we need to share some data structures among
> processes like the limits. Those structures can also be shared among LWPs
> within those processes, and are usually subject to some kind of COW schem=
> so the reference counting and locking gets complicated.
> 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 f=
> of it that makes a lot of sense. It would remove some the complexity arou=
> sharing those data structures.
> That would create problems for threaded applications that use kill() to p=
> 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 =
> could then be mapped onto an LWP in the process for sending signals.
As I understand it, clone() really exists to support older Linux threading=
models. I'm not sure how much their threading still needs this.
If thread-in-process-that-also-has-a-PID-that-points-to-it gives the same=
environment that Linux apps want, do it.
But do we really need this complexity for shared structures? If you use=20
clone(), I think it's reasonable that your "process" is single-threaded.=20
Since your threads are separate processes. Likewise I think it'd be=20
reasonable to prohibit a multi-lpw process from calling clone().
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (NetBSD)
-----END PGP SIGNATURE-----