Deadlock when calling pthread_key_create in the destructor of a pthread_key

Sun Mar 23 23:06:38 GMT 2025

On 2025年03月23日 06:32, Yuyi Wang via Cygwin wrote:
> It's a bug when I tried to run tests of Rust std lib. The standard
> library of Rust tries to create a new pthread_key in the destructor of a
> key created previously. Unfortunately, List::for_each locked the mutex
> before, so List_insert method cannot lock the mutex again.
>> I have searched though the POSIX docs and didn't find any words that one
> should not call pthread_key_create in the destructor of a pthread_key. I
> think it should be a bug of cygwin.

Destructor functions are intended to deallocate key storage at thread exit:
https://pubs.opengroup.org/onlinepubs/9799919799/functions/pthread_key_create.html
"RATIONALE
Destructor Functions
Normally, the value bound to a key on behalf of a particular thread is a pointer 
to storage allocated dynamically on behalf of the calling thread. The destructor 
functions specified with pthread_key_create() are intended to be used to free 
this storage when the thread exits."
although it later says:
"There is no notion of a destructor-safe function. If an application does not 
call pthread_exit() from a signal handler, or if it blocks any signal whose 
handler may call pthread_exit() while calling async-unsafe functions, all 
functions may be safely called from destructors."
-- 
Take care. Thanks, Brian Inglis Calgary, Alberta, Canada
La perfection est atteinte Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add
mais lorsqu'il n'y a plus rien à retrancher but when there is no more to cut
 -- Antoine de Saint-Exupéry