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
> > is allocated for cleanup handlers in tss.cpp on Win32. Again,
> > though, I see nothing documented that says calls to
> > have problems crossing DLL boundaries, and these methods are part
> > 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
> their own separate TLS slot. This is not a problem with tss.cpp
> because Boost.Threads doesn't assume anywhere that this particular
> 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
> DLL will not see the change.
> Again, this is not related to how the RTL is linked, but rather to
> that the EXE and the DLL may have their own copy of Boost.Threads
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk