On Jul 25, 2007, at 12:16 PM, Anthony Williams wrote:

"Graham Reitz" <graham.cpp@gmail.com> writes:

...

Our group has had a lot of success with boost::threads and grown comfortable with its use.

The latest proposal is N2320 (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/ n2320.html), which is largely based on boost.thread, but with movable threads and cancellation. The C++ committee actively discussed this at the recent meeting in Toronto, but there were some areas of disagreement so it has not yet been approved for C++0x. Howard might be able to give more information as he was there.

In a nutshell, cancellation is the elephant in the room, and causing no end of grief for everyone involved. Everyone sees at as something slightly different and incompatible. It is getting renamed, probably to interruption (that is not a committee decision at this point, there are no committee decisions at this point). N2320 proposes cancellation is just another exception that one thread can ask another to throw. There is nothing that special about it. Some would like to see the cancellation exception to be uncatchable. Some would like to see it catchable, but there is an implicit rethrow at the end of the catch clause that can not be turned off. Some would like to see cancellation, once acknowledged by the receiving thread, to be "sticky". Like a subpoena; once you've been served, you have to go. Others prefer to give more control to the thread (allow it to acknowledge then ignore the cancellation). Some would like to see guaranteed interoperability between C cancellation (i.e. pthread_cancel) and C++ cancellation. Others fear this is not implementable on some major platforms (without breaking C (not C++) language ABI). Some would like to see cancellation pulled from the proposal because it is causing entirely too much grief and taking up too much committee time from other issues. There is no issue involving cancellation that has wide spread support. There is no resolution to these issues that does not have vocal objections. If you're into strange entertainment, bring a lawn chair and a martini to a standards meeting, walk into a crowded room and shout "cancellation", set up shop and quietly watch the show. :-) Another major issue is ~thread(): what should it do: boost::thread::~thread() does: if (joinable()) detach(). N2320 proposes std::thread::~thread(): if (joinable()) {request_cancellation(); detach();} Some would like to see: if (joinable()) {request_cancellation(); join();} As long as we're at it, the 4th reasonable solution is: if (joinable()) join(). -Howard

On Jul 25, 2007, at 4:07 PM, Graham Reitz wrote:

Thanks for the reply Howard. It is much appreciated.

I know this a little out of boost scope, but since I have your attention:

I don't know if the other members of the standards committee read this forum, but C++ threads is too important, for something like cancellation disagreements, to prevent it from becoming a C++ standard.

From an academic language perspective, how a thread cancellation proceeds might be important. But for engineers, who are used to using libraries that 'are good enough', we find a way to make things work, elegant or not. Personally, I would take any of the proposed solutions if the alternative was no C++ thread support.

Herb Sutter, at this years SD West Conference, spent a session talking about the future importance multi threaded applications, especially with the rise of multi-core cpus. The memory hole is getter bigger and the expectation is that cpus with numerous cores will be the plug. Based on this assumption, any language that expects to remain the future systems language must have thread support.

(Committee members) Please find a way to compromise and push this through.

Thanks for the feedback. Yes, committee members are reading, and for those that aren't, I'll personally make sure your message is heard. -Howard

I agree w/Graham & Lothar, and it seems rather silly to stifle C++0x on such a debate. I understand the reasoning behind it, but at the same time one must also weigh the costs of being pedandtic about such things. What if C++0x *did not* have thread support, because the committee could not agree on some ideas? From my perspective, I think that would be a bad decision. On 7/25/07, Lothar Werzinger <lothar@tradescape.biz> wrote:

...

Thanks for the reply Howard. It is much appreciated.

I know this a little out of boost scope, but since I have your attention:

I don't know if the other members of the standards committee read this forum, but C++ threads is too important, for something like cancellation disagreements, to prevent it from becoming a C++ standard.

...

From an academic language perspective, how a thread cancellation

On Wednesday 25 July 2007 13:07, Graham Reitz wrote: proceeds

...

might be important. But for engineers, who are used to using libraries that 'are good enough', we find a way to make things work, elegant or

...

Personally, I would take any of the proposed solutions if the alternative was no C++ thread support.

Herb Sutter, at this years SD West Conference, spent a session talking about the future importance multi threaded applications, especially with the rise of multi-core cpus. The memory hole is getter bigger and the expectation is that cpus with numerous cores will be the plug. Based on this assumption, any language that expects to remain the future systems language must have thread support.

(Committee members) Please find a way to compromise and push this

not. through.

...

Thanks again,

Graham

I happen to agree with Graham, it's fundamentally important that threads are going to be part of C++0x. It's good enough to say that the definition of some parts of threading (like cancellation) are delayed for TR2 than not having threading in C++0x.

Lothar -- Lothar Werzinger Dipl.-Ing. Univ. framework & platform architect Tradescape Inc. 111 West St. John Street, Suite 200 San Jose, Ca 95113 email: lothar@tradescape.biz web: http://www.tradescape.biz _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

The C++ committee will not ship the C++0x standard without thread support, period. They'll argue, they'll haggle, but in the end we'll get *something*.

- Doug

Thanks Doug that's really good to hear. Hi Peter, Could you help explain what are some of the arguments/implications are for the competing cancellation proposals? Howard provided an 'in-the-nutshell' response earlier. For us front-line C++ grunt users I would expect the following responses. Issue: "Call it thread cancellation or interruption" c++ grunt response: Don't care what it's called, just give it a concise definition. Issue: "N2320 proposes cancellation is just another exception that one thread can ask another to throw." c++ grunt response: Ok, just indicate where to put the try {} catch {} blocks Issue: "Some would like to see the cancellation exception to be uncatchable. Some would like to see it catchable, but there is an implicit rethrow at the end of the catch clause that can not be turned off." c++ grunt response: Ok, just indicate where to put the try {} catch {} blocks or if it's uncatchable tell fellow grunts not let it happen so program doesn't crash. Issue: "Some would like to see cancellation, once acknowledged by the receiving thread, to be "sticky". Like a subpoena; once you've been served, you have to go. Others prefer to give more control to the thread (allow it to acknowledge then ignore the cancellation)." c++ grunt response: Is the cancellation meant to be a request or an order? Issue: "Another major issue is ~thread(): what should it do?" c++ grunt response: What's wrong with how boost does it currently? Thanks, Graham, c++ grunt On 7/26/07, Doug Gregor <dgregor@osl.iu.edu> wrote:

On Jul 26, 2007, at 1:27 PM, Tim St. Clair wrote:

...

I agree w/Graham & Lothar, and it seems rather silly to stifle C+ +0x on such a debate.

I understand the reasoning behind it, but at the same time one must also weigh the costs of being pedantic about such things. What if C++0x *did not* have thread support, because the committee could not agree on some ideas? From my perspective, I think that would be a bad decision.

The C++ committee will not ship the C++0x standard without thread support, period. They'll argue, they'll haggle, but in the end we'll get *something*.

- Doug

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

Tim St. Clair wrote:

I agree w/Graham & Lothar, and it seems rather silly to stifle C++0x on such a debate.

I understand the reasoning behind it, but at the same time one must also weigh the costs of being pedandtic about such things. What if C++0x *did not* have thread support, because the committee could not agree on some ideas? From my perspective, I think that would be a bad decision.

It's not that simple. Lack of boost.threads-level support in C++0x can be fixed with ease by just using boost.threads, and it's possible to add it in a technical report. Lack of standard cancelation mechanism is practically unfixable. You'll be stuck with it for... basically ever. So C++0x that includes proper cancelation support is infinitely more valuable than C++0x that only includes the basic thread support we already have. It's worth a try.