> 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.
This archive was generated by hypermail 2b29 : Sat Nov 23 2002 - 22:00:19 EST