|
Boost : |
From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-09-07 09:08:04
From: <williamkempf_at_[hidden]>
> This isn't fine. Read the docu for __declspec(thread) carefully. It
> won't work correctly with dynamically loaded libraries, and even if
> your implementation doesn't do this one of your users will.
Thank you for pointing that out, I'll address this issue. What was important
for me was to get the prototype to work.
> Otherwise I'd have gone this route for thread_specific_ptr<> to begin
> with. If there's "weird problems with thread_specific_ptr<>" then we
> should figure out the cause and fix it. Can you elaborate?
I did originally use a thread_specific_ptr<> and got 50% access violations
(after applying Dave's _set_se_translator hack to work around the catch(...)
problem) and 50% hard crashes. That's why I tried the same test with
'vanilla' boost::thread's and got the same weird behavior.
> > 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.
>
> The same argument applies to std::atexit(), and there are work
> arounds for this, so I'd just feel better sticking with the well
> known interface even if we consider it inferior.
No, the same doesn't apply to std::atexit() because you can access global
variables from your atexit procedure. For a thread-specific atexit() you
can't access thread local variables for the main thread, because the main
thread handlers are invoked on process detach. That's why I needed to pass
the pointer value.
-- 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