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@gmail.com> wrote:
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

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