Is this something that's already being worked on? I have some ideas that I've been thinking about to improve Boost.Threads, and some other ideas that have been suggested to me (primarily by Roland Schwarz), that I'd like to at least get other people's opinions of before a Boost.Threads proposal goes too far. Some of the ideas come from the big lock-unification discussion that took place on this list some time ago (although I think I've come up with some interesting ideas on that topic that weren't mentioned in that discussion). I have some other ideas as well that I think people might find intereting.
I'm interesting in reworking some areas of Boost.Threads that I find lacking, so you should probably announce your plans so that we can avoid duplication of efforts.
Sorry if this is not the place to discuss it, but if we have some discussion about threads, I always wondered why thread () constructor launches automatically a thread in constructor. This means that when you code an active class (I mean, I class that represent a task in other thread), if you want to start it on demand, you must use dynamic memory constructing the object in heap. I mainly work in embedded systems that may not have dynamic memory and I think an static way should be provided, since those systems do have threads. I would prefer an option like this: class work_in_other_thread { work_in_other_thread(const boost::function0<void>& func) : m_thread(func){} void start_work() { //this function does not exist in boost threads m_thread.start(); } private: boost::thread m_thread; }; instead of : class work_in_other_thread { work_in_other_thread(const boost::function0<void>& func) : mp_thread(0), m_func(func) {} void start_work() { m_thread = new boost::thread(m_func); } private: std::auto_ptr<boost::thread> mp_thread; boost::function0<void> m_func; }; I see also dynamic memory in proxy functions in the code, but I think it's an implementation detail that could be optimized in systems when needed, storing needed data in boost::thread class if it is a joinable thread. Or we could use an internal, hand-made segregated storage pool for data needed by boost::threads. I don't want to start a flame war, but I would suggest a dual start now/start on demand approach, adding a different constructor and a trigger function. I also think that the standarization of the lock interface is important. Currently, I'm working in shmem library mimicking boost locks/conditions for process-shared locks/conditions. Boost threads explicitly checks for multithreaded build when including thread locks (for example scoped_lock) and it would be nice to reuse those locks in single threaded processes using process-shared mutexes. Ditto for xtime structure. Sorry for the lenghty post about threads, it is just that I couldn't resist it! I would be glad to discuss some boost thread aspects if there is a opportunity for this. Regards, Ion