Boost.Threads review results

From: Ed Brey (edbrey_at_[hidden])
Date: 2001-09-11 09:32:54

The review period for Boost.Threads has concluded.  Boost.Threads is unanimously accepted into Boost.  Congratulations Bill!

Before posting for general consumption, there remain some issues to finalize so as to increase stability and minimize the chance of future interface changes.  Following is a list of interface issues drawn from the reviews which appear most important, and may not yet be fully resolved:

- Should "semaphore" be included in the mainstream distribution?
- What should the policy be for "join" called on a thread a second time?
- What are the specific guarantees of for a function throwing or never throwing an exception, regarding both out of memory and native thread errors?
- Should functions acting on the current thread such as sleep, yield, and join be free or static members of "thread"?
- Is "condition" too generic a name for the boost namespace?
- Should the lock classes be part of the published interface?
- What should the name of the function currently named "join" be?
- What should the names of the functions currently named "up" and "down" be?
- Should "tss" be called "thread_specific_storage"?

In many of these areas, consensus is close if not already reached, and others seem to be moving fruitfully towards a well-thought-through consensus.  Discussion will continue in parallel with Bill's polishing of other aspects of the library.  For any issues yet unresolved once the library is reasonably ready for release, it will likely be more valuable for Bill to make his best estimation of what to do than to delay the library.

There is one implementation issue that is important to get resolved before release, and that is passing the regression tests that use STLport.  Additionally, some nice-to-have features would be optimizing with regard to use of CS/optex/mutex in mutex and a vector/list/set in thread_group as well as clarifying the intent of some code such that it doesn't trigger corresponding warnings.  These nice-to-haves can wait for a subsequent revision, if need be.