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