Tony Juricic wrote:
While intentional TLS slot leak is not a big issue (one expects that OS will do proper cleanup on program exit) it may be confusing to the first-time reader who may have a hard time understanding the motivation for protecting programmers from some leaks, while leaving other leaks to the OS. Reference counting makes it quite clear to the reader what is intended by the code.
I think the issue is not only that a TLS slot will be leaked, but that destructors associated with TSS data will not be called. It is my opinion (I am not sure that this is the general opinion) that a C++ thread library must provide some mechanism to allow thread-specific destructors to be called automatically, in analogue to destructors called at the end of a lexical scope, and at the end of a program execution. In any case, I also think it is a reasonable ideal that all libraries are able to completely clean up after themselves, omitting cleanup only as an optional optimization, as this cleanup is generally valuable for debugging and analysis purposes. Aaron W. LaFramboise