On Sun, 17 Nov 2002, Ingo Molnar wrote:
>
> here are the my current TID-setting changes. It's now 3 clone flags:
Hmm.. I really ahve to say that I just prefer the current two flags, and I
don't see any advantage to the three flag thing, and I do see
disadvantages:
- no real new semantic behaviour.
- the async nature of CLONE_CHILD_SETTID is just bound to cause
interesting-to-debug behaviour
Basically, the current two-flag approach gives all the behaviour the
three-flag thing does, with no downsides:
- if the fork() is a CLONE_VM, the parent/child VM is the same, and the
two flags are really all you need, agreed?
- the the for is _not_ a CLONE_VM, the child is really an independent
VM thing, and we should not even _allow_ the parent to change the VM of
the child: the SETTID behaviour (where it changes the parent VM) makes
sense and is good, but we should probably disallow CLEARTID altogether
for that case (and if the independent child wants to clear its own
memory space on exit, it should just do a set_tid_address() itself)
In fact, from what I can tell, your new CLONE_CHILD_SETTID really is 100%
semantically equivalent to the child just doing a "set_tid_address()" on
its own.
In short, I really don't see the advantage of this patch. I don't think
it's "evil and wrong" in any way, I just think that the lack of reason for
it would argue _against_ making clone() a bit more complicated and
breaking existing behaviour..
Hmm? I _think_ NPTL is fine with the current semantics, right? It just
sets both of the current flags, and that's all it really wants? Uli?
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 : Sat Nov 23 2002 - 22:00:20 EST