Re: Boost.Threads Win32 Implementation

From: bkarsjens (karsjens+yahoo_at_[hidden])
Date: 2001-12-10 11:09:26

--- In Boost-Users_at_y..., "bill_kempf" <williamkempf_at_h...> wrote:
> --- In Boost-Users_at_y..., "bkarsjens" <karsjens+yahoo_at_v...> wrote:
> > 
> > After digging through the implementation of threadmon.cpp, I 
> realized
> > that (unless I missed something) on_thread_exit was always called 
> with
> > the same argument, which is the address of cleanup in tss.cpp. 
> > Therefore all of the stuff in threadmon.cpp for keeping a list of
> > functions registered with on_thread exit were not really needed, it
> > would always have a list of the same pointer. So why not just keep
> > that pointer and call it on thread exit.  I also discovered that
> > DllMain wasn't getting called at all because it wasn't defined as
> > extern "C".  This drastically simplifies threadmon.cpp:
> 
> on_thread_exit, even though it's an implementation detail, is a 
> generalized concept that may be reused in the future.  For instance, 
> I'm considering a static thread::atexit() member.
> 
> [snip code that changed threadmon to not use a list of registered 
> functions]

You still don't really need the registered functions in the DLL.  You
could have thread::atexit() add it's function to the same list as the
thread-specific pointers.  The cleanup_handlers type could be the
current map as well as a set of functions to call at exit.

>  
> > Also, in tss.cpp, cleanup may be called without any handlers
> > registered... I'm not sure if this was always the case, or if I
> > introduced this case, so the cleanup function needs to do an
> > if(handlers) check before actually trying to call them.
> 
> I don't quite follow this one, but I'll research it.
>  
The only thing I can figure out is that get_handlers() was never
called for the current thread.  Since My version of the DLL get the
cleanup functions address and never forgets it, I suppose it is
possible for a new thread that doesn't use tss stuff to never call
get_handlers, but the cleanup function would be called for it anyway.
 And just for the sake of clarity:

    void __cdecl cleanup()
    {
        cleanup_handlers* handlers =
static_cast<cleanup_handlers*>(TlsGetValue(key));
        if (handlers)
                for (cleanup_handlers::iterator it = handlers->begin(); it !=
handlers->end(); ++it)
                {
                    cleanup_info info = it->second;
                    if (info.second)
                        info.first(info.second);
                }
        delete handlers;
    }

> > And now the tests pass!  Wheee!
> 
> Great!  I'll see if I can follow this message in order to get things 
> working in CVS.

Let me know, and I'll give it a test drive.

>  
> > One more thing.  I'm still not convinced for the need of the dll.  
> The
> > issue is needing to know when a thread has exited, and I think that
> > could be done by an object that was destructed in a thread-proxy
> > function.  Since you are already using a thread_proxy function, I'm
> > wondering if you considered this approach and if so, why you 
> rejected
> > it.
> 
> Because of the need for "thread adoption".  Thread A is created 
> outside of Boost.Threads.  A callback is registered with Thread A 
> that uses Boost.Thread's thread_specific_ptr<>.  The memory allocated 
> is never recovered since Thread A wasn't created by Boost.Threads and 
> so isn't using the proxy.

And the light finally dawns on me...  I guess the only other way to do
this would be to create another thread that waits for the thread
handles of other threads created, and that would probably get
complicated fast.

> 
> Bill Kempf