Re: [boost] [thread] Questions/concerns about recent thread lib changes

From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2007-10-15 05:39:51

"Johan Nilsson" <r.johan.nilsson_at_[hidden]> 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