Roland wrote:
However it would be too bad if we needed a _complete_ rewrite of the threading library. Could anyone please drop me some lines why this should be necessary at all?
A complete re-write should not be necessary, but the current model of associating a single method with a thread could be implemented as a specialization of a more object-oriented approach of modelling a thread as a class instance. Another advantage of modelling a thread as instance of a class rather than just a function is that you may elect to implement thread-specific variables as thread class members. This works nicely if you enforce a design rule of a single thread per instance of the Thread class. Some of the things you must do in POSIX style C thread programming, or in the Windows API for thread programming just aren't necessary when using C++ in an object-oriented fashion. C++ provides some natural protections when using threads. For example, POSIX threads must be join'ed to reap the status of the thread and release the thread stack and other resources associated with the thread. C++ destructors come to the rescue here. Another issue to address is the different abstractions that the different operating systems use. For example, Windows allows a thread to be created in a suspended state -- but emulating suspended initial state is fairly easy to implement in POSIX threads. I wouldn't, though, want to saddle non-Windows programmers with an emulation they don't need nor desire. This suggests a low-level Thread class that is almost a lowest common denominator on all platforms, with child classes that model the extensions of the various platforms. The extensions are implemented natively on the platforms that offer it, and emulated on those that don't. I'd like to see the synchronization objects separated into their own portion of the threads library because some synchronization methods require non-C++ standard implementations -- the volatile keyword isn't the same thing as a LOCK prefix or direct assembly language access to CAS instructions. Work in this area should be directed at suggested changes in the C++ standard to address multiprocessor problems. I mention these issues because I don't think the original Boost threads library fully considered them. I'd like to see these issues and others discussed before we jump in and implement. Glen