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

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

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

> 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.


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