[boost] Re: Thread lib (good reason for static)

From: Michael Glassford (glassfordm_at_[hidden])
Date: 2004-06-11 12:56:04

"Malcolm Noyes" <boost_at_[hidden]> wrote in message
news:nbojc05l4vscs8jth4rneuhaj56tertm7f_at_4ax.com...
> On Fri, 11 Jun 2004 07:14:40 -0400, in gmane.comp.lib.boost.devel
> Michael Glassford wrote:
>
> >I assume this means that "attach" callbacks are called before the C
> >library's and "detach"
> >callbacks are called *after* the C library's? Otherwise it's not a
> >problem, as Boost.Thread's tss cleanup is interested primarily in
> >detach callbacks (a process attach callback would be used to call
> >TlsAlloc(), but that should work regardless of whether the C
library
> >is loaded).
>
> I agree - loading shouldn't be a problem, however wouldn't you need
to
> have the C runtime loaded so that when the tls cleanup handler runs
it
> has access to functions that may be called during object releasing -
> for example a custom cleanup handler might call 'free', and this
might
> fail, if I understand correctly ?

Yes. However, it seems to me that the C library will be available in
the normal scenario of a thread detaching when the process isn't
exiting, and that it will only become unavailable when the process is
exiting, which, as I mentioned below, could be treated as a special
case where cleanup is not attempted (better: is performed by some
other mechanism).

All this is assuming that the C library is actually unloaded too soon,
which AFAIK hasn't been verified yet.

> Also, my impression is that this is related in some way to
> __declspec(thread) variables which suggests that:

That's what I was thinking, too, though I haven't attempted to verify
it yet.

> a) this may not work well for dynamically loaded DLLs (i.e.
> LoadLibrary, not statically linked to the stubs)

Presumeably dllmain will work here, however--if we can hook into it.

> b) we'd probably need to check that whatever mechanism works for
MSVC
> doesn't break __declspec(thread) variables.
>
> Both will be pretty easy to check, of course.
>
> >It may not be much of a problem, anyway, except when the cleanup is
of
> >a sort that must be performed even on process exit, which seems
> >unusual to me for thread-specific storage. What I mean is, if
> >necessary, the tss cleanup could detect that the process is exiting
> >and stop trying to run cleanup commands (to prevent access errors,
> >etc.), "leaking" any resources stored in thread_specific_ptr
objects.
> >It seems to me that for many applications such leaking wouldn't be
> >much of a problem (but I may be wrong).
>
> I think I'd agree, and for any 'corner cases' it's always possible
to
> require a call to 'tss.reset(0)' to free the resources before the
> process exits.

Or, hopefully, there might be another way to force a cleanup of all
threads if the process is exiting.

> >> >Hmm. So an application whose tls cleanup required 'C' library
> >> >functions would probably fail.
> >
> >That's what it sounds like to me--but only when the process is
> >exiting, I presume?
>
> That was my understanding as well; having read the relevant bits of
> the documentation it almost looks like the TLS callback 'hooks' were
> put there to implement just what we need.  My only concern would be
> why they never got implemented (it appears to have been in the PE
> format for some time) - maybe someone from MS can enlighten us . . .
>
> >I'm not seeing this.
>
> Sorry - didn't explain myself very well.  Application to be tested
> does this:

[snip code showing what it does]

OK, that makes sense. But I don't understand what the problem is,
then--unless you're thinking that some Win32 API functions won't be
available at the point where the tss cleanup is called?

> Thus monitor 'knows' about all threads in test app.  I'm planning to
> implement this as a test case for the three variations of 'fixes'
that
> I outlined the other day (i'm working on test cases for 2 of these
> variations now ;-).

Good!

> >Please do: I'm very interested.
> So am I, and having read the docs (and not being an expert on
> linking), I can't begin to imagine how Aaron will make it work with
> MSVC, but I'll be very happy if it does work ;-)  Good luck Aaron!

Mike