Re: [PATCH v3] move the definition of __pthread_tsd_main to the only compilation unit that references it

[Jens Gustedt <jens.gustedt@inria.fr>]

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

Am Montag, den 11.02.2013, 12:14 +0100 schrieb Szabolcs Nagy:
> * Jens Gustedt <Jens.Gustedt@inria.fr> [2013-02-11 11:44:21 +0100]:
> >  - Avoids a const cast that doesn't seem to be very useful.
> >  - Remove unused __pthread_tsd_size
> > 
> 
> sorry i was wrong, __pthread_tsd_size is used in pthread_create
> (i haven't read all the mails yet)

oops, somehow I must have got my grep for it wrong then, sorry for the
noise.


> the logic is that it is 0 when pthread_key_create is not
> linked to your code so you avoid all the tsd stack overhead
> (which is reasonable: in small tools where size and memory
> usage matters most you don't often use thread specific data..
> especially now that c11 has tls)
> 
> same for pthread_self: you only want non-dummy tsd if
> pthread_key_create is used
> 
> with your change you break pthread_create (now __pthread_tsd_size
> is always 0 there) and pthread_create always pulls in the tsd buf

Ok, now I see the idea.

In case of dynamic linking, this sounds a bit dangerous to me. Suppose
I have a program that runs fine, without linking to the key stuff. Say
it launches a new thread which then has the key table invalid.

Then I dynamically load a module that uses keys. The thread that has
an invalid table jumps into a function of that module that calles
pthread_key_get() ?

In such a scenario everything would simply crash, wouldn't it?

Jens

-- 
:: INRIA Nancy Grand Est :: http://www.loria.fr/~gustedt/   ::
:: AlGorille ::::::::::::::: office Nancy : +33 383593090   ::
:: ICube :::::::::::::: office Strasbourg : +33 368854536   ::
:: ::::::::::::::::::::::::::: gsm France : +33 651400183   ::
:: :::::::::::::::::::: gsm international : +49 15737185122 ::




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