Re: [patch] threading fix, tid-2.5.47-A3

[Linus Torvalds]

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