Re: Boost.Threads Win32 Implementation

From: bill_kempf (williamkempf_at_[hidden])
Date: 2001-12-10 10:05:21

--- In Boost-Users_at_y..., "bkarsjens" <karsjens+yahoo_at_v...> wrote:
> The first thing I discovered when trying to get threads working is
> that the -mthreads option was not being used in jam.  I added the
> following to the gcc-tools.jam file.  I'm not totally sure it's 
right
> -- it's needed for mingw32, but I don't know if it is necessary for
> cygwin.
> 
> if $(NT)
> {
>     flags gcc CFLAGS <threading>multi : -mthreads ;
>     flags gcc LINKFLAGS <threading>multi : -mthreads ;
> }

Thanks.  This may help me with the current problem we're having with 
gcc.

> Adding that let's gdb actually work on it... It doesn't crash deep 
in
> the bowels of thread exiting in some kernel library routine.  
Although
> it still crashes in on_thread_exit doing handlers->push_front
(func). 
> Actually, it crashes in some STL stuff, but that's I'm not sure why,
> I'm not that good with gdb yet.
> 
> 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]
 
> 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.
 
> And now the tests pass!  Wheee!

Great!  I'll see if I can follow this message in order to get things 
working in CVS.
 
> 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.

Bill Kempf