[lkml]   [2002]   [Aug]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:28    [W:0.234 / U:4.284 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site