[PATCH 2/2] Add support for LinuxThreads.

[Leonard Crestez]

On 10/22/2013 11:16 PM, Jason Evans wrote:
> On Oct 21, 2013, at 2:12 PM, Leonard Crestez <lcrestez at ixiacom.com> wrote:
>> When using LinuxThreads pthread_setspecific triggers recursive allocation on all threads. Work around this by creating a global linked list of in-progress tsd initializations.
>>
>> This modifies the _tsd_get_wrapper macro-generated function. When it has
>> to initialize an TSD object it will push the item to the linked list
>> first. If this causes a recursive allocation then the _get_wrapper
>> request is satisfied from the list. When pthread_setspecific returns the item is removed from the list.
>>
>> This effectively adds a very poor substitute for real TLS used only
>> during pthread_setspecific allocation recursion.
>>
>> Signed-off-by: Crestez Dan Leonard <lcrestez at ixiacom.com>
>> ---
>>   include/jemalloc/internal/tsd.h | 63 +++++++++++++++++++++++++++++++++++++++++
>>   1 file changed, 63 insertions(+)
> I don't see how this code can work.  It stack-allocates block (struct tsd_init_block block;), then permanently links it into a ring.  There are other less critical issues (e.g. no cleanup during thread exit, using pthread_mutex_t rather than malloc_mutex_t, and coding style conformance), but let's worry first about whether there's a feasible way to restructure the initialization code.
Hello,

The link is not permanent, it is temporary until pthread_setspecific 
returns. The stack-allocated block is inserted in the list by 
tsd_init_checkrec and removed by tsd_init_finish, immediately after 
pthread_setspecific returns. It is allocated on the stack because the 
lifetime is so short. Unless a lot of threads are created the list will 
only contain at most one item during the first allocation on each thread.

I can replace pthread_mutex_t. What should I fix about the coding style 
to make it acceptable? Should I move the tsd_init_* inside the 
malloc_tsd_funcs macro or to some separate file?

Regards,
Leonard