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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 15 2002 - 22:00:32 EST