|
Boost Users : |
From: bill_kempf (williamkempf_at_[hidden])
Date: 2001-12-11 15:38:29
--- In Boost-Users_at_y..., "bkarsjens" <karsjens+yahoo_at_v...> wrote:
> --- 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.
This just makes the code harder to decipher, IMHO. In the end none
of this matters, though, as it's simply part of the implementation.
> > > 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.
Not to mention it would be a tremendous waste of resources ;).
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