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.
> > 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.
if CLONE_VM is set then the TID is set immediately, before sys_clone()
returns. Or are you worried about the fork() case?
> 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 be fine to me, but i wanted to get away with a single pointer.
> 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).
we do not want to do yet another syscall. Also, this makes the TID value
nonatomic - debugging code would have to know whether the child has
already executed the syscall.
Ingo
-
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:19 EST