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.