> the attached patch
-> The patch that was meant to be attached :)
> the solution is to add a new syscall that sets the current->user_tid
> address. This new syscall is used by glibc's exec() implementation.
I don't understand this: why would glibc use it in exec()?
> Another change is to make CLONE_SETTID work even if CLONE_VM is not used.
> This means that the TID must be set in the child's address space, not in
> the parent's address space. I've also merged SETTID and CLEARTID, the two
> should always be used together by any new-style threading abstraction.
But this prevents using SETTID to get the tid in a
signal-handler-accessible place before a SIGCHLD can arrive, without
having to use sigprocmask.
How about renaming CLONE_SETTID to CLONE_SETTID_PARENT, leaving the
existing semantics alone, and adding a CLONE_SETTID (with a new value)
that sets the tid in the fork child?
This would require two separate tid pointers so that glibc could
implement a fork_get_pid(int* pid) setting pid in the parent vm and the
tid in struct pthread in the child.
Alternatively, if the fork child calls sys_set_tid_address on its own
right after creation, no modifications to clone are required (this is
what my sys_cleartid patch did).
BTW, user_tid needs to be cleared on exec, and I'm not sure if we are
doing this.
This archive was generated by hypermail 2b29 : Sat Nov 23 2002 - 22:00:19 EST