Re: Boost Jam question: how to set "features"?

From: williamkempf_at_[hidden]
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.  
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.

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 
programmers.

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 
alluding to.

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 
niave user!

> Multithreaded programming is a rather advanced style of 
programming, most
> 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 
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.

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" 
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.

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 
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.

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 
not
> inherently unsafe and b) it is something Boost.threads should 
support "out
> of the box".

I'll look into it for a future release.

Bill Kempf