|
Boost Users : |
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
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net