From: Michael Glassford (glassfordm_at_[hidden])
Date: 2004-06-11 12:56:04
"Malcolm Noyes" <boost_at_[hidden]> wrote in message
> 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
> >is loaded).
> I agree - loading shouldn't be a problem, however wouldn't you need
> have the C runtime loaded so that when the tls cleanup handler runs
> has access to functions that may be called during object releasing -
> for example a custom cleanup handler might call 'free', and this
> 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
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
> 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
> 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
> >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
> >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
> 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'
> I outlined the other day (i'm working on test cases for 2 of these
> variations now ;-).
> >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!
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk