Re: [boost] [thread] feature request priority

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<https://svn.boost.org/trac/boost/ticket/5150>
>> boost::thread does not print or return the error value when
>> creating a thread fails.
>>
>> I planed to implement it via
>>
>> #6230 <https://svn.boost.org/trac/boost/ticket/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.
> 

Yes.

>> and
>> #3696 <https://svn.boost.org/trac/boost/ticket/3696> Boost
>> Thread library lacks any way to set priority of threads
>> via
>>
>> #2741  proposal to manage portable and non portable thread attributes
>> <https://svn.boost.org/trac/boost/ticket/2741>
> 
> 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.
> 

OK.

> 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,
Vicente

--
View this message in context: http://boost.2283326.n4.nabble.com/thread-feature-request-priority-tp4167017p4256831.html
Sent from the Boost - Dev mailing list archive at Nabble.com.