This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC PATCH glibc v2] pthread_setspecific: Provide signal-safety across keys


----- On Oct 18, 2017, at 7:37 AM, Szabolcs Nagy szabolcs.nagy@arm.com wrote:

> On 18/10/17 06:33, Florian Weimer wrote:
>> * Mathieu Desnoyers:
>> 
>>> @@ -327,7 +328,7 @@ __nptl_deallocate_tsd (void)
>>>  	    {
>>>  	      /* The first block is allocated as part of the thread
>>>  		 descriptor.  */
>>> -	      free (level2);
>>> +	      (void) munmap (level2, PTHREAD_KEY_2NDLEVEL_SIZE * sizeof (*level2));
>>>  	      THREAD_SETMEM_NC (self, specific, cnt, NULL);
>> 
>> I think __nptl_deallocate_tsd needs to disable signals as well, even
>> when the level2 pointer is NULL, and keep them disabled until the
>> thread exits.  This is not a localized change; I don't know if it is
>> safe.
>> 
> 
> dtors must not run with signals blocked (posix does not
> say that dtors may see changed signal mask)

Would it be more acceptable to have a "thread_exiting" flag,
and have pthread_{get,set}specific return NULL and EPERM
respectively when invoked from dtors and from signal handlers
nested over thread teardown ?

> 
> i think it's the user's fault if there is async
> pthread_getspecific call while a thread is exiting.
> the user can block the signals before thread exit
> if that's the intended behaviour.

In the lttng-ust tracer use-case, I cannot change the application.
A simple library could be instrumented, and use lttng-ust for
tracing, without any change to the application. So unfortunately
the solution you are proposing does not work in my case.

Thanks,

Mathieu


-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]