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

From: williamkempf_at_[hidden]
Date: 2001-11-13 09:47:48

--- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> From: <williamkempf_at_h...>
> > If by "per-thread state" you mean TLS slots, yes it does.  A TLS 
slot
> > is allocated for cleanup handlers in tss.cpp on Win32.  Again,
> > though, I see nothing documented that says calls to 
TlsAlloc/TlsFree
> > have problems crossing DLL boundaries, and these methods are part 
of
> > the Win32 API not the RTL so should be totally unaffected by the
> > linkage option chosen for the RTL.  Or am I missing something
> > important?
> 
> Yes, TlsAlloc/TlsFree are not affected by the RTL.
> 
> The problem that I'm speculating about is that the EXE and the DLL 
will have
> their own separate TLS slot. This is not a problem with tss.cpp 
AFAICS
> because Boost.Threads doesn't assume anywhere that this particular 
TLS slot
> is unique.
> 
> If, on the other hand, you decide to keep a per-thread flag ("bool
> canceled", say), in a situation where the EXE sets this flag to 
true, the
> DLL will not see the change.
> 
> Again, this is not related to how the RTL is linked, but rather to 
the fact
> that the EXE and the DLL may have their own copy of Boost.Threads 
(with its
> own statics.)
> 
> As I said this is not currently a problem.

Ahh!  You aren't talking about the original issue of linkage type for 
the RTL.  You're discussing solely whether or not a program links to 
Boost.Threads statically or dynamically.  Gotcha.  Currently there's 
one choice... a strange hybrid of static and dynamic linkage with 
most of Boost.Threads in a LIB and the threadmon in a DLL.  I'm 
working on moving Boost.Threads fully into a DLL.  At that time I 
don't know if I'll support static linking at all or not.  I'm leaning 
towards not supporting static linking at all.

Bill Kempf