The automatic "thread stop" functionality relies on non-standard behaviour

[mattcaswell]

We have the function OPENSSL_thread_stop(_ex) so that an application can explicitly clean up thread local data when a thread is no longer going to be using OpenSSL. Most applications don't need to use it though because our implementation automatically detects when a thread is exiting and cleans up the thread local data automatically.

The automatic detection of a thread exiting works by registering a thread destructor callback when initialising a thread local data key:

openssl/crypto/initthread.c

Lines 195 to 209 in d318411

	static void init_thread_destructor(void *hands)
	{
	init_thread_stop(NULL, (THREAD_EVENT_HANDLER **)hands);
	init_thread_remove_handlers(hands);
	OPENSSL_free(hands);
	}
	int ossl_init_thread(void)
	{
	if (!CRYPTO_THREAD_init_local(&destructor_key.value,
	init_thread_destructor))
	return 0;
	return 1;
	}

Other sections of the code also use thread local keys but they rely on the centralised detection of a thread exiting for cleanup. They simply register a callback with the centralised mechanism and the callback gets called when cleanup is necessary. It is done this way for portability reasons so that the same mechanism can be used on all platforms.

However, at least with pthreads on Linux (windows threads not tested), it was found during the development of #24344 that the thread local data for the RCU code was being set to NULL before the centralised callback mechanism could clean it up. This turns out to be because, with pthreads on Linux the thread local data is cleaned up by the platform in the order that the thread local keys were created. If there is no destructor then the thread local data just gets set to NULL. So if a thread local key gets created before the centralised thread local key, then thread local data is always set to NULL before the centralised handling can clean it up.

The workaround for this problem in #24344 is to ensure that the centralised thread local key is always created first. But this relies on the ordering that thread local data is cleaned up being standard for all pthreads implementations. AFAIK this is not the case??

Tasks

Beta Give feedback

1. Investigate possible implementations to provide consistent freeing model for thread local data project#552
   +0
   
2. investigate removal of ossl_thread_stop as adjunct to this project#553
   +0
   
3. Implement proposal from #552 when consensus reached project#558
   +0