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
