
"Johan Nilsson" <r.johan.nilsson@gmail.com> writes:
Sean Huang wrote:
The thread lib has recently gone through drastic changes. These much needed changes are very welcome and I really appreciate Anthony's work and efforts. We use boost::thread heavily in our mission/performance critical application and the quality and stability of the boost::thread code is paramount to us. With the recent changes and what happened in that process, I felt that it is necessary to raise my concerns to the community. If these concerns have already been addressed and managed, I sincerely apologize for generating this noise and being paranoid.
I'm personally also a bit concerned, not as much for implementation changes as for possible interface and/or semantic changes. Being an optimist, I believe that by the time the Boost.Thread library is released as part of an official Boost release, the implementation should be of sufficient quality.
Thanks for the vote of confidence.
What I don't want to do, however, is to change my existing client code because of interface/semantic changes. If there are breaking changes, my suggestions would be to put the new (or to preserve the old) code in a separate namespace.
Which features are important to you? Breaking interface changes so far: * Lock types are now namespace level rather than nested typedefs. * There is no seperate try_mutex * scoped_lock constructors that take a bool parameter removed in favour of explict try_to_lock, defer_lock overloads. * timed_lock functions now take boost::system_time (a typedef to boost::posix_time::ptime from the date_time library) rather than xtime * call_once order of arguments has been reversed, pending addition of support for passing arguments to the once function. Backwards compatibility support: * Overload of call_once added with existing arguments, which forwards to new version * scoped_lock typedefs left in mutex types * try_mutex left as a typedef Breaking changes coming soon: * Condition variables changed in line with new C++0X thread proposal. Non-breaking changes coming soon: * Thread launching changed in line with new C++0x thread proposal. This shouldn't break existing code, as the existing thread interface is so narrow. Anthony -- Anthony Williams Just Software Solutions Ltd - http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL