|
Boost : |
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk