Jonathan Turkanis wrote:
Stefan Strasser wrote:
I don't vote because I have not (yet) looked at the library itself, but from the review replies so far I'd like to moot that it may be too early to include a singleton library which:
- is not MT safe - is not tested with shared libraries - seems not to be tested with many compilers(...several newer compilers...)
The third point is no big deal. A lot of porting often occurs after acceptance.
I agree that MT support is crucial, and that shared library support is very important, if i is possible. Rather than reject the library because these problems haven't been addressed, let's try to address them during the review.
Jonathan
I don't think its fair to say that it is not MT safe... the MT aspects just have not yet been extensively tested. There is a lock policy in place, which is intended to lock the singleton in the lock's constructor, and release the lock in the lock's destructor. A lock is used during creation, destruction, and access of any of the singleton's members via a proxy pointer. The only thing missing is a lock class that actually performs the locking, and I am under the impression that Boost.Threads probably provides something matching this description. -Jason