Re: [patch] clone_startup(), 2.5.31-A0

[Linus Torvalds]

On Tue, 13 Aug 2002, Christoph Hellwig wrote:
> > This one definitely isn't a pthread-specific problem. The old UNIX fork()  
> > semantics for <pid> returning really are fairly broken, since the notion
> > of returning the pid in a local register is inherently racy for _anything_
> > that wants to maintain a list of its children and needs to access the list 
> > in the SIGCHLD handler.
> 
> The TLS setting makes it pretty pthread-specific, though (or at least
> thread-specific).

That's certainly true, and potentially worth a clone() flag of its own, 
quite independently of the startup thing ("CLONE_SETTLS").

Ingo, how about breaking it down that way? 

>	  Also the fn parameter makes it very different from
> both clone and fork. 

The fn thing is a purely user-mode effect, it's not there in the system 
call. Which is true of a regular clone() too.

> What about spawn() if you dislike a thread in the name?

spawn() to me implies doing the equivalent of "vfork()+execve()", the way
most non-UNIX OS's do new process creation.

I don't dislike the "thread" name too much, but I want this to be generic, 
and seen as such. The same way the original clone() was a proper superset 
of fork(), this needs to be a proper superset, not just in name, but in 
_usage_. If it's useful for only one thing, that's not good.

			Linus