RE: [boost] Re: Boost Jam question: how to set "features"?

From: Steve Anichini (sanichin_at_[hidden])
Date: 2001-11-11 18:02:36

> From: williamkempf_at_[hidden] [mailto:williamkempf_at_[hidden]]
> Will it compile when statically linked to the RTL?  Of course.  Would
> this cause problems for all programs built this way?  Probably not.
> 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 application,
> while the cleanup runs in the DLL.
>

From my analysis of the code the allocation and destruction will both occur
with the EXE version of the RTL. In tss.cpp, you register cleanup() with
on_thread_exit(). cleanup() is the static library of boost.threads, and
therefore uses whatever instance of the RTL the app is using, assuming that
the app and the static boost.threads library have the same library.

All that threadmon.cpp does is call it's cleanup handlers. If those cleanup
handlers are linked with the app, as is the case with the one in tss.cpp,
they are using the EXE's RTL. The call to cleanup() in tss.cpp from
threadmon.cpp crosses back across the EXE/DLL boundary into the EXE "space".
So for your usage, both allocation and deallocation are occuring in the EXE
space.

One way what you describe can happen is the following:
        1. the user creates some object or something in the EXE
        2. the user passes that object to a DLL.
        3. The DLL wraps it with a thread_specific_ptr.
        4. On thread destruction, the destruction of the object occurs in DLL
space.

But #2 clearly may break the rules for passing heap objects across EXE/DLL
boundaries. So even if steps #3 and #4 were not present (i.e. the user was
not using Boost.threads), they are already using dangerous practices, and if
they haven't used the known workarounds (virtual destructor or new/delete
overloads), things would break without Boost.threads.

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.
Multithreaded programming is a rather advanced style of programming, most
novices aren't going to attempt it. Exporting C++ objects and interfaces
from DLLs is another advanced idiom - most of what you need to know to get
it to work correctly is buried deeply in the knowledge base and/or comes
from having been burned with C++ and DLLs in the past. I've known many
experienced programmers, having been burned by C++ and DLLs in the past,
just make it a rule never to mix C++ and DLLs. I think that's going too far
(once you know the issues, it's rather easy to craft objects that can be
safely exported from DLLs), but it is a valid stance.

In summary:
        1. Linking with the DLL runtime is definately the "most safe" option and
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.

> 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 the
> frustration caused by the decision to only link dynamically against
> the RTL for certain advanced users, but the dangers involved are
> simply too great.  If you insist on statically linking you'd better
> 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 capable of
modifying it to suit my needs. But I've learned many hard lessons about
modifying third party code - don't do it unless you absolutely must. Because
modifying Boost in order to support what I want means I have to manually
merge the changes back in every time I want to update to the latest version
of Boost.

Hence why I'm lobbying that a) linking with the static runtime is not
inherently unsafe and b) it is something Boost.threads should support "out
of the box".

-steve