|
Boost Users : |
From: Graham Reitz (graham.cpp_at_[hidden])
Date: 2007-07-26 16:46:10
> 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_at_[hidden]> 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_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net