[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: fstrcmp: memory is not reclaimed on exit

From: Akim Demaille
Subject: Re: fstrcmp: memory is not reclaimed on exit
Date: Wed, 19 Feb 2020 15:07:35 +0100

Hi Bruno,

> Le 16 févr. 2020 à 13:52, Bruno Haible <address@hidden> 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  <address@hidden>
>       fstrcmp: Add API to clean up resources.
>       Reported by Akim Demaille <address@hidden> 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!

reply via email to

[Prev in Thread] Current Thread [Next in Thread]