Hi Bruno,
> Le 16 févr. 2020 à 13:52, Bruno Haible <br...@clisp.org> a écrit :
>
> Hi Akim,
>
> Sorry for the delay.
You look busy :)
>> +void
>> +fstrcmp_free (void)
>> +{
>> + gl_once (keys_init_once, keys_init);
>> + gl_tls_key_destroy (buffer_key);
>> + gl_tls_key_destroy (bufmax_key);
>> +}
>
> This workaround is insufficient, since POSIX [2] says that
> "It is the responsibility of the application to free any application
> storage or perform any cleanup actions for data structures related
> to the deleted key or associated thread-specific data in any threads"
>
> In other words, pthread_key_delete is not guaranteed to call the destructor
> of 'buffer_key'. The gnulib test (tests/test-tls.c functions
> test_tls_dtorcheck1
> and test_tls_dtorcheck2) verifies that the destructor gets called, but only
> for threads != main thread, and you are interested in the main thread
> particularly. Most likely, in this test, the destructor gets called when the
> thread exits [3], not when pthread_key_delete gets called.
Thanks for the details. The main thread is really not like the others.
> This patch, however, should work.
>
>
> 2020-02-16 Bruno Haible <br...@clisp.org>
>
> fstrcmp: Add API to clean up resources.
> Reported by Akim Demaille <a...@lrde.epita.fr> in
> <https://lists.gnu.org/archive/html/bug-gnulib/2020-01/msg00080.html>.
> * lib/fstrcmp.h (fstrcmp_free_resources): New declaration.
> * lib/fstrcmp.c (fstrcmp_free_resources): New function.
It looks good to me, thanks!
