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.

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. 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.) 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. 4. I wonder if a thread should own its attributes such that clients can query for them later: thread_attributes const & thread::attributes() const; _____ Rob Stewart robert.stewart@sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

Vicente Botet wrote:

Stewart, Robert wrote

...

Vicente J. Botet Escriba wrote:

...

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.

That's a reasonable first step.

...

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.

Yes and no. Consider thread_group: you can't easily associate the attributes with a thread, if you have access to a thread_group and not the code that called add_thread(). BTW, does the patch address creating threads, with attributes, via thread_group::create_thread()? _____ Rob Stewart robert.stewart@sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.