Re: [boost] Re: Thread Lib and DLL
William E. Kempf [EMAIL PROTECTED] writes: Russell Hind said: I'd been wondering this, and heard about TLS issues. The issues are only on Windows it appears. Search for the thread Fwd: Thread-Local Storage (TLS) and templates by Greg Colvin on 18/02/2003 Specifically, the many posts by William Kempf and Edward Diener discuss the problems on windows with TLS cleanup. I do have a question on this issue: If this problem is only to do with TLS cleanup when a thread exits, then if all threads are created when the program starts and only destroyed when the program exited, then, in practice, could this really be an issue? I.e. if we only work like this, could building thread as a static lib cause problems providing that we don't let threads exit in the middle of the program? We're currently really trying to stay clear of any DLLs. Theoretically at least, I don't see why this would cause a problem. You intentionally leak, but the leak is benign since it occurs only right before the application exits. But most users won't code this way, nor do I want to have to deal with the support requests/questions this would cause. So, unless you have some suggestion as to how I can enable this usage with out causing confusion, I'm not sure I'd care to re-enable static builds. But you could probably fairly easily hack things to build that way yourself. I don't really understand the issues here, but I was wondering if you could reclaim leaked TLS resources lazily somehow, by looking for unused TLS the next time new TLS is requested. Just a thought... -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Thread Lib and DLL
Yes, cleanup could be solved this way (or with other approaches, daemon thread, periodic timers, etc). However, I don't see cleanup as the core issue with making TLS work without a DLL under Win-32. Currently, boost.threads supports (uses/specifies) the POSIX style cleanup model where the cleanup function is called on the thread that is closing. This cleanup function can also set/get/clear TLS values (which should continue to be valid for the closing thread until it exits [read: right after the cleanup func finishes]). Boost.threads TLS/DLL approach is used to fire off the cleanup function on the closing thread. There are also issues with this [DllMain single-dispatch rules, someone waiting in a cleanup handler, and others], but this approach at least allows boost.threads under Win32 to conform to it's own specification. [ Note: Windows internally seems to have been fixed by MS at some point to dispatch DLL_THREAD_DETACH in a reverse-dependency order, which makes sure that the DLL that was most recently loaded is the first to receive DLL_THREAD_DETATCH messages. Without this behavior, DLL TLS support would have serious issues in even working out of the box. The reason this seems to be a fix by MS at some point, is that the DLL_THREAD_ATTACH order is *NOT* in dependency order, but in what appears to be link order. Perhaps someone from MS can comment on the implementation, and how it came to follow these [undocumented] rules. ] For boost.threads stand-alone lib, the only solution I currently see is: - Relaxation of the cleanup function handler requirement from WILL BE CALLED, to MAY BE CALLED from the closing thread. If this was done, then Unix implementations would continue working as is (call from cleanup func in closing thread), and windows implementation would have a worker thread(s) dispatch the cleanup handler functions when threads were shutdown (this thread would wait on the thread object when TLS values were in use on a particular thread). Note, the calls to the win32 boost TLS functions can be made to work correctly if dispatched from a cleanup-handler, which is what we want. However, OS level functions, [GetCurrentThread() and friends] would yield the thread of the cleanup dispatcher thread which is indeed incorrect. Since *few* people do fancy things in TLS [usually they deallocate/free resources], and *even less* people call other TLS functions from cleanup handlers, and *even less* people call OS-thread functions inside their TLS cleanup handlers, I see the change in the specifications to be reasonable. With something like this I see a valid (if complex in implementation) way to support boost.threads as a static lib. Willam Kempf has be gracious enough to discuss many of the issues at length with me and has examined various approaches to solving the TLS / DLL dependency issues. At first I thought it should be possible to solve, but I now feel that solving it within the scope of the current TLS-cleanup handler specification is impossible without modifying the specification (from WILL to MAY call from the closing thread). Here Bill and I disagree :-). Bill feels that the specification should not be changed, since this is an OS-brokenness issue that can be corrected by MS at some point in the future. I feel, that the boost thread specification should be modified for this (very rare) corner case, in order to support Win-32 static lib builds of boost.threads. I don't see any right or wrong here, as it is fundamentally a matter of specification. - Steve PS I also share Bill's desire to find a workable solution to this problem. However, I am pessimistic that there exist solutions that work under Win-32 and conform to the boost thread TLS spec rules for cleanup handlers. -Original Message- From: David Abrahams Sent: Saturday, March 29, 2003 10:16 AM I don't really understand the issues here, but I was wondering if you could reclaim leaked TLS resources lazily somehow, by looking for unused TLS the next time new TLS is requested. Just a thought... -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Thread Lib and DLL
Russell Hind said: I'd been wondering this, and heard about TLS issues. The issues are only on Windows it appears. Search for the thread Fwd: Thread-Local Storage (TLS) and templates by Greg Colvin on 18/02/2003 Specifically, the many posts by William Kempf and Edward Diener discuss the problems on windows with TLS cleanup. I do have a question on this issue: If this problem is only to do with TLS cleanup when a thread exits, then if all threads are created when the program starts and only destroyed when the program exited, then, in practice, could this really be an issue? I.e. if we only work like this, could building thread as a static lib cause problems providing that we don't let threads exit in the middle of the program? We're currently really trying to stay clear of any DLLs. Theoretically at least, I don't see why this would cause a problem. You intentionally leak, but the leak is benign since it occurs only right before the application exits. But most users won't code this way, nor do I want to have to deal with the support requests/questions this would cause. So, unless you have some suggestion as to how I can enable this usage with out causing confusion, I'm not sure I'd care to re-enable static builds. But you could probably fairly easily hack things to build that way yourself. -- William E. Kempf ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Thread Lib and DLL
Russell Hind said: William E. Kempf wrote: Theoretically at least, I don't see why this would cause a problem. You intentionally leak, but the leak is benign since it occurs only right before the application exits. But most users won't code this way, nor do I want to have to deal with the support requests/questions this would cause. So, unless you have some suggestion as to how I can enable this usage with out causing confusion, I'm not sure I'd care to re-enable static builds. But you could probably fairly easily hack things to build that way yourself. No, I wasn't going to ask you to re-enable static linking because of this. As you rightly pointed out in the other thread, you have to make the library safe for all possible cases which is what you are doing. If we did decide to go this route, then we would certainly handle building the lib ourselves. Our problem with DLLs is this: We work on many projects. Some are in maintenance only mode, so don't get many updates. The next project may use boost-1.30.0 and then go into maintenance. I may then be working on a project which uses boost-1.32.0 and would like to keep both dlls available on the system. You can do this simply by placing the applications in seperate directories and keeping the proper DLL version alongside the executable. Not necessarily the ideal solution, but it's the easiest way to solve DLL Hell. Current idea for doing this is re-naming the boost dlls to boost_thread-1.30.0.dll etc so that I can have 1 bin directory with all the dlls in, and each project would link and use the correct dll. I wonder if support for this could be built into the builds? Absolutely! I'm hoping we address these kind of concerns with a full installation solution sometime soon. In the mean time, the stage rule in the Jamfile should be able to handle this. You can hardcode the release number in today... but I believe there's a variable available which I could use to do this with out hardcoding. I'll see if I can track this down and make the patch. -- William E. Kempf ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Thread Lib and DLL
Edward Diener said: William E. Kempf wrote: David Brownell said: I am curious as to why the new version of the Thread library does not provide a static library in the 1.30 version of boost. After reading some initial posts, I have seen references to thread local storage, but haven't seen anything that documents why this makes a static library impossible. All thing considered, I find a static library is much more desirable than a dll. It has been discussed numerous times on this list, as well as on the Users list. TLS cleanup can only be done on the Win32 platform with code in the thread itself (which won't work for threads created outside of Boost.Threads) or with code in DllMain. A possibility. Simulate the DllMain DLL_PROCESS_DETACH through a member function call in the thread class which should only be used for those who are using a static library version of the library. The member function must be called before the thread function exits in the static library version. For the DLL version, the member function must be ignored or you can simply not have the member function call in the DLL version. The onus would be on those using the static library version to always make this call before their thread function exits, but would at least provide them wioth the possibility of using a static library version. Of course there may be other ramifications which cause this idea not to work, or even getting it to work properly would be too much trouble, but I thought I would suggest it anyway. Workable, if the user makes absolute certain he calls this method from every thread that accesses TLS. However, he may not know this, for example when a library function uses Boost.Threads internally and allocates TLS with out the user knowing. This is just a variation on the you must use this thread creation routine if you use our libraries solution that MS uses for the C RTL and MFC. I think it's fragile... and many users fail to understand the issues here and thus do the wrong thing. It may not be worth thinking about possible solutions of building a static library version of Boost.Threads. I know that for myself I always creates DLLs when distributing applications but as a 3rd party developer I always leave open the possibility that there are people who like to distribute the applications as a single EXE which uses static libraries and the static library version of their compiler's RTL. Yes, and for that reason I certainly dislike the DLL only packaging of Boost.Threads. But it seems the safest and most viable solution. -- William E. Kempf ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
