< lots of good suggestions snipped > I agree that threading needs to find its way into the standard and hope enough progress is made soon to make this a reality. I hope many aspects from the shmem library and others are considered to enrich the basic functions currently offered by boost threads. This would improve the utility of a 'threads' submission in my opinion. I also think that thread priority and scheduling need to be implemented in some form. I appreciate that in certain OSes this isn't possible, but if such priorities/scheduling types were hints which an implementation were free to ignore then why couldn't these feature as say optional constructor parameters or in a member function for adjusting priority/scheduling type. I couldn't find the mailing list discussion (that I expect did happen) regarding the reasons not to include priority etc.in the interface, but would be interested if their inclusion may be possible in future revisions of boost thread. I also find the notion of creating a new thread and monitoring an existing thread being represented within the same class (with different constructors) as being slightly non-intuitive. This may be one of many areas where boost threads could benefit from a more tutorial-based set of documents rather than a purist model/concept set of docs. Paul