From: Johan Nilsson (r.johan.nilsson_at_[hidden])
Date: 2007-10-16 03:34:18
Anthony Williams wrote:
> "Johan Nilsson" <r.johan.nilsson_at_[hidden]> writes:
>> 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?
All that enable my code to compile and work as previously without changes?
Also, having the POSIX thread implementation handling EINTR during sleeps
would be great. I'm currently using a wrapper for calls to thread::sleep to
avoid spurious wakeups.
> Breaking interface changes so far:
> * Lock types are now namespace level rather than nested typedefs.
No problem as there's the mutex::scoped_lock typedef compatibility.
> * 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.
I can appreciate the explicitness, but this is still a problem as the
interface changes. I rarely use the option to not lock the mutex initially,
but it has happened.
> * timed_lock functions now take boost::system_time (a typedef to
> boost::posix_time::ptime from the date_time library) rather than xtime
If you are going to make a breaking change - why not add an time_duration
overload, please? Even if almost everything is better than the current xtime
interface, I've so far never had a requirement to use an absolute time for
waiting or sleeping. Absolute times is most often just a real pain to use,
and in its current implementation also misleading.
(I've read the rationale in Programming with POSIX Threads, but I'm not
[snip remaining breaking + compatibility changes]
I just came to the conclusion that there's no point in me commenting on all
the changes. If I really have to, I can adapt our code to use the new
threading interface even though I'd prefer not to. But - if the new stuff +
the compatibility changes will all exist in the same namespace it feels like
it's going to be a source of confusion, as there will be multiple ways of
doing the same thing.
Why not put the new thread implementation in e.g. boost::std0x::thread and
have the current Boost.Thread delegate to the new implementation using an
unchanged interface (wherever technically possible)?
I'll read through the n2320 proposal as soon as I get some time.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk