From: Peter Dimov (pdimov_at_[hidden])
Date: 2004-04-20 06:39:23
Christophe Meessen wrote:
> First we where not very happy with boost threads because it requires a
> copy of the functor object. This does not allow to put non copyable
> object as member variables of the functor object. Knowing that mutex
> are none copyable objects, for good reasons, one understand that this
> API is far too constraining. I guess such design choices was driven
> by the requirement that the functor object lifetime is tighlty linked
> to the thread lifetime.
This is not correct. It does not require a copy. Use ref(). Or bind(&X::run,
shared_ptr<X>(new X)), if you prefer to stay "object oriented".
It creates a copy by default because this is the safer alternative (the
lifetime of the function object is managed by the library).
> The thread object is the obvious place to use as thread local storage.
The general drawback of using member variables as thread local storage is
that (a) you need 'this' in order to access them, (b) if a low-level routine
needs TLS data in order to make itself reentrant (or to achieve better
performance - thread-specific free lists come to mind as an example), it
can't allocate it itself; you'll need to change the thread class and add a
member. Which makes low-level library design a bit difficult.
This is a common theme; many approaches work fine in a tightly controlled
environment, when you write all of the code, but do not scale to
distributed, modular environments.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk