The user can just call the method for every thread which uses Boost.Threads in a static library implementation. If a library ( LIB ) function uses Boost.Threads internally, then it is up to the library function implementor to document this and iteratively define a function which can be called which calls the Boost.Threads function before the thread ends or, if the library function itself controls the ending of the thread, it must do it itself.
Or, it could be packaged up in a simple object wrapper (which is what I am doing) and the destructor automatically calls it for me.
I use an auto_ptr to a wrapper object as the functor that gets passed to Boost.Threads which points to the object I want to actually "execute" (since I don't want to copy its data around each time in the internals of boost. That object is derived off a simple base whose destructor could call the Boost.Threads::Release() function on termination. What this solution (or the previous proposed) does not seem to solve is abnormal termination, which the DLL does solve.
One other possible solution, for those of us who want to package Boost into our own DLL, but link it in statically so the linker can only pull in the parts used, is to provide a DLL template object that our DLL derives off of with functors for each of the calls that you normally get in a DLL. The boost framework calls the Release as needed, then calls the user Functor. I do not know how this fares in other environs. Should I expound on this idea or is it a waste of time?
michael
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
