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

[Luca Barbieri]

--=-7y1SA/jnJJkVFoXdZd8h
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

> On 17 Nov 2002, Luca Barbieri wrote:
>=20
> > I don't understand this: why would glibc use it in exec()?
>=20
> 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.) Thi=
s
> 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()" =3D=3D "in the initialization code for the exec'ed program"?
=20
> if CLONE_VM is set then the TID is set immediately, before sys_clone() =20
> 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.

--=-7y1SA/jnJJkVFoXdZd8h
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQA915nDdjkty3ft5+cRAijKAJ4sZmNbAJicJMj/WE80GhKTe6QKgwCcCshV
8etLyltsXWvUmlX6OaBxCCc=
=Hyna
-----END PGP SIGNATURE-----

--=-7y1SA/jnJJkVFoXdZd8h--