Re: [boost.thread] Experimental alternative TLS implementation
I just downloaded Roland's implementation and I quite like it. By the way, congrats Roland on resolving TLS callback issues for static link library for VC6 and VC7; after digging into it as I joined the group I was too busy but now I hope to have more time and, at least, help with more testing. 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 wonder what are current plans for the future of threads libray, after a lot of discussion about rewrite? My own perspecitive is colored by everyday practical use: for example, I never encountered any need for thread-specific pointer but I often had to pass a boolean to thread proc to make a thread stop. Consequently, and as I would like to use boost threads instead of my own concotion, I would like to see "thread stopping pattern", lacking better term and just for example, as the part of the interface. I understand these are difficult issues but after quite a few years of using threads I am not sure that I still find 'older' Java-like thread(s) interface particularly useful. Tony
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
"Aaron W. LaFramboise" wrote
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.
I don't think that intentinally leaked slot has anything to do with not invoking object destructors?? Anyway, syntactically and sematically thread ptr looks to me more like: { Object* po=new Object(); ... delete po; // still need this in C++, it is not Java } than like: { Object o; ..... } but there is nothing wrong with the automatic cleanup, if it is available. The 'tricks' needed to get it to work with MSVC are not attractive but "if you don't need t don't use it" argument is strong enough. Instead of concetrating on what is in there and what already works, I wonder what other new features will people like to see? For example, I used threads mostly for network programming and, stated very broadly, would like to see some additional infrastructure that would make such programs more generic. Also, lock free and/or wait free containers would be interesting additions. They are not directly related to threads classes but are interesting for some high-performance multi-threaded applications. Tony
participants (2)
-
Aaron W. LaFramboise -
Tony Juricic