$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: Peter Dimov (pdimov_at_[hidden])
Date: 2006-07-20 10:42:52
Anthony Williams wrote:
> "Peter Dimov" <pdimov_at_[hidden]> writes:
>
>> Anthony Williams wrote:
>>> Can we have a call to TlsFree in on_process_exit, so we don't leak
>>> the TLS slot either?
>>
>> It's better not to. We don't leak a TLS slot because TLS slots are
>> per process. When the process is terminated by the OS, all of its
>> TLS slots are "reclaimed" (more precisely, they simply cease to
>> exist.)
>>
>> So we gain nothing because the lack of TlsFree is not observable.
>
> The same could be said of just about everything that the OS cleans up
> --- handles, memory, etc.
Correct. The only reason to do redundant cleanup is because of inadequate
leak detectors and user complaints.
>> On the other hand, if on_process_exit is called when some threads
>> are still running, TlsFree'ing the slot will make it impossible for
>> these threads to clean up after themselves since they won't be able
>> to access their cleanup handler lists. This can be observable if
>> their cleanup handlers have visible side effects.
>
> on_process_exit is called when the module is unloaded. If there are
> any threads running at that point which are referencing code in that
> module (e.g. because they use boost thread cleanup handlers), they
> have bigger problems than the fact that the TLS slot has been freed
> --- the whole module is being unloaded.
If on_process_exit is guaranteed to be called after all on_thread_exits (if
it's called at all), it will indeed be safe (but still redundant) to TlsFree
the slot in it.