Re: [boost] [thread] Questions/concerns about recent thread libchanges

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:
>

[snip]

>
>> 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 
convinced.)

[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.

/ Johan