Messages in this thread | | | Date | Tue, 13 Aug 2002 09:20:49 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: [patch] clone_startup(), 2.5.31-A0 |
| |
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/
| |