Hi, "Peter Danford" <pdanford_qed@yahoo.com> wrote in message news:20040602024428.45768.qmail@web60606.mail.yahoo.com...
I'm not sure other than the reasons regarding optimizations possible with statically linked libs. I know that there is also some overhead involved in calling dll functions as opposed to the static counterpart, but this surely is a small cost. Other than that, I am not sure.
As you are running VS.NET 2003, you could try the (free) community edition of Compuware's profiler, downloadable from: http://www.compuware.com/products/devpartner/profiler/default.asp Instrumenting your application (and boost.thread) should help you to find out the reason for the performance degradation when using the runtime linked version. And, yes, I second the opinion to make a statically linked version available - even without or with limited support for TSS/TLS. [following is windows-specific stuff] I seem to recall that the reason for requiring a dynamically linked version was solely for automatically cleaning up thread_specific_ptr's at thread exit - is that right? I've in the past made a solution based on lazy cleanup of previously allocated TLS data - i.e. when someone attempts to alloc a TLS (aka TSS) slot/data, the currently invalid data (belonging to an "ex-thread") is deleted. This requires some metadata to be globally available to all threads, and that this data is tagged with the owning threads id, but is certainly doable. It could also be possible to expose a manual TLS-data "garbage-collection" routine, e.g. "collect_tss_data", for the user's really nedding it. Not beautiful, but considering the options ... There are a few potential problems though (off the top of my head): 1. Performance - each creation of thread-specific data required exclusive access to the metadata. If this is a real issue or not depends on the real-world scenario. Developers sensitive to this should anyway try to create only one thread_specific_ptr to host all their TSS data. Also, TLS slots are a limited resource (especially under earlier NT versions). Or is this automatically managed by the current TSS implementation? 2. Operating system's reuse of thread id's. This could (in theory) cause data to be hanging around longer than necessary, but should otherwise not be causing problems as each thread should only be able to access data created by themselves. 3. Destruction-time for TSS data would be indeterminate (unless explicitly clearing things up). HTH // Johan