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-tp4167017... Sent from the Boost - Dev mailing list archive at Nabble.com.