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
"Malcolm Noyes" <boost@alchemise.com> wrote in message news:nbojc05l4vscs8jth4rneuhaj56tertm7f@4ax.com... 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:
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'
[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? 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