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

From: Michael Glassford (glassfordm_at_[hidden])
Date: 2004-06-11 06:14:40

"Aaron W. LaFramboise" <aaronrabiddog51_at_[hidden]> wrote in message
news:40C94580.5070600_at_aaronwl.com...
> Malcolm Noyes wrote:

[snip discussion of GSS & MSVC implementations]

> >>I also neglected to mention that this feature may be unusable, in
> >>general, because the TLS callbacks are called before the C
library's
> >>are. This means that stdio and the heap may not be fully
availible, at
> >>least for MSVC.  The standard C library (and perhaps other DLLs?)
need
> >>to expect that they may not be notified first of ctors/dtors.
MSVCRT
> >>may do this, but I am not sure.  I don't know what garentees there
are
> >>about MSVCRT.DLL being notified before any other loaded DLL,
anyway.

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).

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).

> >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?

> >An application that required a TLS
> >cleanup handler that (for example) aquired a process shared mutex,
> >fiddled with some process shared memory and then released the mutex
> >might work, but would anyone like to guarantee it (without support
> >from Microsoft)?   I know that this is a 'corner case' that some
would
> >consider boost::thread doesn't need to support; my imagination has
run
> >as far as a monitoring application that uses a process shared mutex
to
> >'watch' the threads created and destroyed by some other application
> >(the one that we want to test) - I have applications now where a
> >utility like this could be useful.  You could do this by allocating
a
> >thread_specific_ptr object that recorded the process id, thread id
and
> >optional name of the thread on thread startup; thread_specfic_ptr
> >object destruction would remove the thread from the list in the
> >'monitoring' application.

I'm not seeing this. Do you mean that the watching application would
create a thread_specific_ptr object for a thread in the other
application? I don't see how that would work: AFAIK the Win32 API Tls*
functions don't work that way. Even if they did, it sounds like you
would need static Tls unload messages from the other application, and
I don't see how that would work, either.

Unless you mean that the watched application is monitoring its own
threads and telling the watcher application when they are attached and
detached?

> > Another way to do this would be to use
> >sockets - anyone like to wager anything on whether this might work
> >with TLS callbacks ?
> >
> >
> I'm not sure exactly what happens.  It needs testing, but in any
case,
> I'm sure there are no documented garentees.  I also think some hack
to
> work around problems, if they are problems, could be made to work
reliably.
> I do feel fairly strongly that the ability to nondeterministically
call
> destructors for objects in dynamic TLS is important, and acheivable,
> somehow.

I agree.

> The "I think this can work but I can't really say for sure" is due
to me
> not having time to tear into this yet.  Since interest in this
mechanism
> has been indicated, I will definitely look into this and get the
answers
> with regards to its usability within a few weeks.  Hopefully then I
will
> be able to say more definitively, "Yes, Boost can use this, and this
is
> how" or whatever.

Please do: I'm very interested.

Mike