Date: 2001-11-12 10:17:55
--- In boost_at_y..., "Steve Anichini" <sanichin_at_2...> wrote:
> > From: williamkempf_at_h... [mailto:williamkempf_at_h...]
> > Will it compile when statically linked to the RTL? Of course.
> > this cause problems for all programs built this way? Probably
> > However, the chances of the user getting things wrong here are
> > EXTREMELY high, especially considering that the sole purpose of
> > threadmon is to cleanup thread specific storage which will almost
> > assuredly be allocated on the heap using the RTL by the
> > while the cleanup runs in the DLL.
> From my analysis of the code the allocation and destruction will
> with the EXE version of the RTL. In tss.cpp, you register cleanup()
> on_thread_exit(). cleanup() is the static library of boost.threads,
> therefore uses whatever instance of the RTL the app is using,
> the app and the static boost.threads library have the same library.
Yes, after sending my response (which I did in a hurry) I thought all
day long about how I didn't explain myself well. And while trying to
think of how to explain myself better I couldn't come up with a good
example of how this could be done accidently even by knowledgable
Any way, the problem isn't with the Boost.Threads library (even
if/when it's turned into a DLL which is planned) but with it's use by
multiple DLLs and/or the executable. Which ever DLL or executable
creates the thread_specific_ptr<> will register it's version of
cleanup with the slot. If another DLL or the application then sets
the TLS pointer with a call to thread_specific_ptr::reset() passing a
pointer to memory it allocated you get the problem we've been
However, for anyone familiar with DLL programming and it's resource
issues (which unfortunately isn't a very large number) the above
description should be an obvious programmer error. Maybe I'm being
overly paranoid in this case, but I've had to deal with these sorts
of issues a few too many times. Out of a force of habit I just
habitually use dynamic linking to the RTL for this reason unless I
have very specific reasons not to (which is extremely rare for
myself). I'll have to reconsider my stance here.
> But I argue that in most cases the only types of users who are
going to be
> attempting mixing EXEs, DLLs and Boost.threads are advanced ones.
I don't buy this argument... I've been bitten too many times by
issues identical to this particular case. Never underestimate the
> Multithreaded programming is a rather advanced style of
> novices aren't going to attempt it.
My experience is the opposite. MT programming looks enticingly
simple. In fact many MT books claim that it really is. My
experience shows that novices generally create threads at the drop of
a hat while experts avoid them like the plague.
> Exporting C++ objects and interfaces
> from DLLs is another advanced idiom - most of what you need to know
> it to work correctly is buried deeply in the knowledge base and/or
> from having been burned with C++ and DLLs in the past. I've known
> experienced programmers, having been burned by C++ and DLLs in the
> just make it a rule never to mix C++ and DLLs. I think that's going
> (once you know the issues, it's rather easy to craft objects that
> safely exported from DLLs), but it is a valid stance.
This is another area where our experiences differ. As an MFC
programmer I find it very common for novice and expert alike to
frequently create MFC extension DLLs.
> In summary:
> 1. Linking with the DLL runtime is definately the "most safe"
> should remain the default.
> 2. Linking with the static runtime is only slightly less
safe, and should
> at least be supported as an option within the official distribution.
I'm swayed, though I'm not as convinced as you about the safety of
statically linking. I'm worried about support issues, but I'm no
longer convinced that's a compelling enough reason to fight this.
> > The concept that a programmer can follow some simple rules and get
> > this correct is usually not accurate. The rules are simply not
> > simple and are hard to insure that you follow them. I understand
> > frustration caused by the decision to only link dynamically
> > the RTL for certain advanced users, but the dangers involved are
> > simply too great. If you insist on statically linking you'd
> > know what you're doing, and in that case you really don't need the
> > supplied build system any way.
> No, I don't need the supplied build system, or I'm certainly
> modifying it to suit my needs. But I've learned many hard lessons
> modifying third party code - don't do it unless you absolutely
> modifying Boost in order to support what I want means I have to
> merge the changes back in every time I want to update to the latest
> of Boost.
You don't have to modify the code at all, though. You only have to
set up your own build process. This does mean you may have to modify
your build system when new releases add or remove source files, but
this isn't the same headache as modifying the code.
> Hence why I'm lobbying that a) linking with the static runtime is
> inherently unsafe and b) it is something Boost.threads should
> of the box".
I'll look into it for a future release.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk