From: Michael Hunley <mhunley@pocketpurchase.com> At 09:56 AM 2/11/2003 -0500, you wrote:

...

Sorry, I forget that some acronyms aren't known by everyone. TLS stands for "thread local storage", also known as TSS or "thread specific storage".

Thanks for clearing that up.

...

Testing and development. I compile against 5 compilers, and with both static and dynamic libraries this means compiling 10 variants at a minimum (through in both debug and release and you have 20 variants), which is time consuming. But the real kicker is that boost::thread itself is going to rely on TLS shortly, making it so you'll always need a DLL on the Windows platforms.

Understand & sympathize. What about people who want to bundle that part into their own DLL (which is largely what I'm doing)? Does it hurt to leave the build in and doc it as untested?

Short term, probably not. Long term even this won't work.

Also, why would inclusion of TLS require it to be a DLL?

By itself, TLS doesn't require this. However, TLS cleanup *does* require this. (We're still trying to find an alternative, because even this approach to TLS cleanup is fraught with peril.) The MS APIs do not give you any means with which to cleanup data allocated to TLS, and they recommend you add this in DllMain. This is why you have incompatible thread creation routines such as CreateThread, _beginthread(ex) and AfxBeginThread.

It would seem like including TLS could also be done in a static lib or am I being completely obtuse?

TLS, yes, TLS cleanup, no.

On an almost related note, I saw mention of a cooperative cancel policy from another post of yours. Do you have any ETA on that and any info on what it will support vs what it won't support? Is that info on the developer mailing list?

It's partially implemented in CVS on a branch named "thread_dev" (though this isn't stable). ETA is hopefully very soon, as the C++ standards meeting looms. William E. Kempf wekempf@cox.net