Anthony Williams wrote:
Phil Endecott <spam_from_boost_dev <at> chezphil.org> writes:
In November Sergey Skorniakov wrote to this list asking about the non-thread-safety of Boost.Function and consequently of Boost.Thread itself. Steven Watanbee replied pointing out that the problem is resolved in the trunk.
Irrespective of any fixes applied to boost.Function, this has been fixed in the trunk --- boost.thread no longer depends on boost.function.
It was fixed on the trunk for Boost.Function long ago. It's interesting that the thread library no longer depends on 'function' (at least, for launching threads); I see how the change was done (using virtual functions, which was once the implementation trick used in Function), but I'm curious as to why? Function has some storage optimizations that will tend to make it more efficient that the basic virtual function/templated derived class idiom. - Doug