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

[Luca Barbieri <ldb@ldb.ods.org>]

[-- Attachment #1: Type: text/plain, Size: 1283 bytes --]

> On 17 Nov 2002, Luca Barbieri wrote:
> 
> > I don't understand this: why would glibc use it in exec()?
> 
> i suspect the idea would be to always make every process a proper pthread
> object as well. (but Ulrich will correct me if this is not the case.) This
> means that across fork() we can set up the TID pointer via CLONE_SETTID,
> and after exec() we need the new set_tid_address() syscall to initialize
> it.
"after exec()" == "in the initialization code for the exec'ed program"?
 
> if CLONE_VM is set then the TID is set immediately, before sys_clone()  
> returns. Or are you worried about the fork() case?
Yes.

> this would be fine to me, but i wanted to get away with a single pointer.
Using two pointers would allow to provide all the functionality
mentioned in the discussion on your first clone/tid patch
<http://www.uwsg.iu.edu/hypermail/linux/kernel/0208.1/1409.html>.

Calling sys_set_tid_address after fork is equivalent (but non-atomic)
but requires an additional system call.

> Also, this makes the TID value
> nonatomic - debugging code would have to know whether the child has
> already executed the syscall.
Debugging tools already need to be aware of this for process
initialization, so this shouldn't be a serious problem.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]