Boost logo

Boost :

Subject: Re: [boost] [thread] feature request priority
From: Vicente Botet (vicente.botet_at_[hidden])
Date: 2012-01-03 08:53:50

Stewart, Robert wrote
> Vicente J. Botet Escriba wrote:
>> Respect to
>> #5150<>
>> boost::thread does not print or return the error value when
>> creating a thread fails.
>> I planed to implement it via
>> #6230 <> Follows
>> the exception reporting mechanism as defined in the c++11
> I presume by referring to #6230 that you'll throw an exception of type
> system_error for #5150's case. If so, I agree.


>> and
>> #3696 <> Boost
>> Thread library lacks any way to set priority of threads
>> via
>> #2741 proposal to manage portable and non portable thread attributes
>> <>
> Using a thread_attributes class seems fine, but there are a few issues
> with #2741:
> 1. thread::thread_attributes makes for a redundant name. Either
> "thread_attributes" or "thread::attributes" would be better.


> 2. The constructors that take a thread_attributes argument should overload
> the existing constructors, not replace them. (The class definition in
> #2741 suggests the possibility of no backward compatibility, but I think
> that is important.)

Yes, this is the case. The provided patch adds overloads without replacing
the previous thread constructor..

> 3. You could support a portable interface for thread priorities, but you'd
> need to determine how to normalize thread priorities since different OSes
> offer different ranges of priority values. It might be that the portable
> interface provides only partial prioritization support for some platforms,
> requiring the use of a native API when that's insufficient. That would
> give some support for portable code, even if a modest utility that might
> be enough for many applications. Then again, the result might be so
> anemic that it would never be used.

My first intention was to provide the minimum, so that users are able to use
the non-portable interface.
I'm not sure we can provide a useful and portable interface for thread
priorities, scheduling, .... The user could always define a class inheriting
from thread_attributes and provide an interface that is portable for his
application, which is less than requiring a portable interface in the
generic sens. I will try to add an example in the documentation so that the
user could find inspiration for his own application.

> 4. I wonder if a thread should own its attributes such that clients can
> query for them later:
> thread_attributes const &
> thread::attributes() const;

The user can always associate the passed attributes to the thread either
passing them as parameters or/and setting them as a thread specific pointer.
I will try to add also an example.

I will prefer to let this possibility for later development if there is a
real need.
Thanks for your comments,

View this message in context:
Sent from the Boost - Dev mailing list archive at

Boost list run by bdawes at, gregod at, cpdaniel at, john at