EmptyCrate Software. Travel. Stuff.

One of the things that called my attention in boost::thread is that it offers a different solution from other object oriented technologies: ACE or Java come to mind now.

In ACE or Java threads, there is a thread object from which you derive and provide implementation of a specific virtual method [svc() in ACE, run() in Java]. One of the dangers of this approach and a common pitfall is that users often commit the error of providing a thread adapter hierarchy that offers solutions for different problems:

class BaseThread : ACE_Base_Task { ... }; // Thread RAII
class PeriodicThread : public BaseThread { ... }; // Adds periodic operations support
class PeriodicSender : public PeriodicThread { ... }; // Real worker

where BaseThread is in charge or RAII (creates the thread in the constructor and the destructor joins the thread), PeriodicThread adds periodic funtionality (as an example) calling a virtual method with a given periodicity. Finally PeriodicSender is the real worker class.

The problem is that during construction ACE_Base_Task is first initialized, then BaseThread, that creates the thread. At this point the thread will be started and it can call virtual methods from PeriodicThread or even PeriodicSender. But this objects are not yet created.

I like boost::thread approach of dividing the thread and the real worker in different classes so that during construction (and launching of the boost::thread class) the worker is already perfectly created. The approach shown in the article somehow contradicts this philosophy by reuniting thread and worker classes. After reading the article, first thing that comes to mind is using a hierarchy as the one shown above to ease the burden of rewriting thread code during construction and destruction.

Just writting a note telling users to initialize the thread as the very last thing in the construction process does not seem too secure a solution.