|
Boost : |
From: Michael Glassford (glassfordm_at_[hidden])
Date: 2004-06-03 14:02:29
"Peter Dimov" <pdimov_at_[hidden]> wrote in message
news:00b101c4495e$72390730$0600a8c0_at_pdimov...
> Peter Danford wrote:
> > By introducing the tss into the thread implementation mentioned
> > below, are we gaining functionality so useful it outweighs the
> > benefit realized by having a static option available?
>
> This is a question we better not get into. ;-)
>
> A brief history. At first, Boost.Threads supported static linking.
It used a
> helper DLL (threadmon.dll) to implement TSS cleanup on Windows. At
that time
> I suggested to Bill Kempf that (a) it might be useful to isolate the
> mechanism in a dedicated "at_thread_exit" function exported by
> threadmon.dll, thereby allowing users to implement their own cleanup
(or to
> omit it entirely if they know that their application does not
continually
> create and destroy threads) and (b) that if Boost.Threads is
implemented
> itself as a DLL (as pthreads-win32 is) there would be no need for a
separate
> threadmon.dll.
>
> Now obviously (b) without (a) - the current status quo - is somewhat
> problematic for people that don't like DLLs or the DLL runtime (of
which I
> am one). So I think that we ought to implement (a) as well;
statically
> linking to Boost.Threads would then result in an unresolved
reference to
> at_thread_exit, expecting a suitable definition from the user (or
from
> at_thread_exit.dll, which we'd also supply). The DLL version of
> Boost.Threads should, of course, continue to work out of the box,
with no
> user intervention required.
I like the idea. I had vague thoughts along those lines, but hadn't
really formulated anything yet. Now that you mention your discussion
with Bill Kempf, which I wasn't aware of before, I see signs in the
code that he was working in that direction. I'll see what I can do to
finish it.
> It is very unfortunate that Bill is no longer active, or even
reachable for
> comment. I wonder what happened to him.
I agree.
Mike
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk