Re: [boost] Re: boost.threads: Thread pool

From: William E. Kempf (wekempf_at_[hidden])
Date: 2003-01-30 01:58:01

Alisdair Meredith said:
> "William E. Kempf" wrote:
>
>> > [Michel André]
>> > Another question i noted that in the current boost CVS the
>> boost.thread only builds a dll version of the library and no static
>> ones, in earlier release you only needed the dll when using tss? Is
>> it supposed to be that way?
>>
>> Yes.  It vastly simplifies the build process (now that we have a
>> working DLL implementation), and is the version most users have been
>> asking for any way.  I did expect to get some static about this, so
>> let the debate begin. ;)  Note, however, that it will be a little
>> problematic to continue with a build process that provides both a
>> forms, and that the
>> threadmon.dll has been the source of a lot of confusion for users, so
>> there will have to be very compelling reasons to bring this build type
>> back.
>
> OK, here's some static!!
>
> As you know from an earlier thread I aim to finally investigate
> boost::thread this week (as a largely drop-in replacement for our
> compiler vendor-supplied thread library)  A static build is important to
> us, as we have found many support/development issues simply vanish with
> a static build.  We would be very reluctant to move to a system
> requiring such a .dll, especially if it means using the dynamic RTL with
> our compiler (as that is where we generally hit the problems above)

OK, but remember that this has always been a requirement on Windows
platforms any way (well, technically you could get by with out the
threadmon.dll if you used no thread_specific_ptr<> instances, but this
ability may disappear shortly any way, as the implementation will have to
use TSS data, and the only way to clean up such data on Win32 platforms is
by hooking into DllMain).  Knowing this, do you still feel as strongly? 
If so, I'll listen, but I'm not sure I'll have much choice here in the
long run.

> I am also unsure how a standard proposal might look if we can only say
> 'the dynamic library version works well, but we have problems with the
> static' although I have no experience of the committee to be sure.  I
> would give me pause for thought.

Well, if the library becomes part of the standard, I would expect that MS
would have to do something about this glaring hole in the Win32 API (and
fixing this would be trivial for MS).  (And yes, I realize that a C++
standard technically has no bearing on MS C API, but I also believe that
they'd respond to public pressure on this one.)  On the Win32 platform
today you have three choices (one of which isn't always an option): 
explicitly delete the TSS data before a thread ends (which is only an
option when you control the creation of all threads that access the TSS
slot), hook into DllMain, or leak memory.

> What problems does the static build bring?  Would it be useful for
> someone who does care about static builds ( thinking of no-one in
> particular <g> ) to look after the issue?

I think I outlined the problem above well enough for you to understand the
issue, but if I need to give more detail, just ask.  Other than the
DllMain hook, the only solution I've been able to come up with is to stub
the call to CreateThread, but this has many complications of its own, and
may still leak memory if any threads were created before the stub was put
in place.  An unlikely corner case, maybe, but still certainly possible
(especially for library developers), so I rejected this alternate
solution.  I've asked some contacts at MS for alternative solutions, but
none have been provided to me.  If you, or anyone else, can find a better
solution I'd be greatly appreciative, but I fear that there is no other
solution available.

William E. Kempf
wekempf_at_[hidden]