Re: [Boost-users] Any update on a form of boost::threads getting into the C++ 0x standard?

From: Graham Reitz (graham.cpp_at_[hidden])
Date: 2007-07-25 16:07:39

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

Graham

On 7/25/07, Howard Hinnant <howard.hinnant_at_[hidden]> wrote:
>
> On Jul 25, 2007, at 12:16 PM, Anthony Williams wrote:
>
> > "Graham Reitz" <graham.cpp_at_[hidden]> 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
>
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>