Boost logo

Boost :

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-09-07 05:04:42


From: "William Kempf" <williamkempf_at_[hidden]>
> From: "Peter Dimov" <pdimov_at_[hidden]>
> >The on_thread_exit service exposed by threadmon.dll is very useful on its
> >own (for win32 developers.) Perhaps it deserves to be documented?
>
> It's an implementation detail and should not be used directly. What I
have
> considered was adding a boost::thread::atexit() method. I'm reluctant to
> add to the interface during this review, but if it's considered important
> enough I'll do this.

Yes, I know that it is an implementation detail, however it's very useful to
me (as an implementation detail of my prototype thread::ref design.)

Of course I can build my own threadmon2.dll but I wanted to reuse as much of
Boost.Threads as possible; I hope that you don't mind. ;-)

> >I suggest the following improvement: change
> >
> >void on_thread_exit(void (*) ());
> >
> >to
> >
> >void on_thread_exit(void (*) (void *), void *);
> >
> >(rationale: when on_thread_exit is called to register a function for the
> >main thread, by the time the function is invoked, all thread-specific
> >variables are already gone.)
>
> I don't follow this. The thread_specific_ptr<> already handles cleanup of
> thread-specific data and so boost::thread::atexit() would not be needed
for
> cleanup of this type. Passing a pointer to thread-specific data to
atexit()
> is going to result in an error since the data will have already been
> reclaimed. I personally think that boost::thread::atexit() should use the
> same syntax as std::atexit(). That's why I coded on_thread_exit() that
way.

I ran into some very weird problems with thread_specific_ptr (which fits my
needs perfectly in theory) so I had to replace it with a __declspec(thread)
raw pointer to thread::state. This is fine since I don't actually need to
'delete' this pointer _unless_ the thread has been adopted, in which case I
allocate a new thread::state and wanted to use
on_thread_exit(delete_thread_ref) to avoid the memory leak. Alas, I can't
pass it the pointer as a parameter. ;-)

In any event, I think that the ( void (*)(void*), void* ) pair is a good
thing to have in general since you can build a version that takes an
arbitrary function object on top of it, whereas the current version can't
handle this.

--
Peter Dimov
Multi Media Ltd.

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk