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 10/19/2017 12:42 PM, Mathieu Desnoyers wrote:
> Good points! This brings me to a third approach that would
> fit my use-case, and perhaps be more generic than the
> pthread_setspecific_np approach. We could introduce a
> new as-safe "query" function, e.g. pthread_exiting(),
> which could be called by the application to conditionally
> decide not to invoke pthread_setspecific() from dtors and
> signal handlers nested over dtors. In applications like a
> tracer, or liburcu-bp trying to register a thread, doing
> that registration while in the thread dtors is pretty much
> useless, so it could be simply skipped.

APIs that check status usually have lifetime decidability issues
with the objects they check. This is a deep design topic. I'm
not going to delve too deep here.

To be honest what I'd like to see from you before we go down the
deep topic of API design is this:

A detailed writeup of your use case and the behaviour you're trying
to support.

I still don't have a clear grasp on what appears to be two rather
specific requirements for the library and threads it creates.

-- 
Cheers,
Carlos.


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