Re: [boost] Boost.Threads, N2178, N2184, et al

From: Stefan Seefeld (seefeld_at_[hidden])
Date: 2007-03-26 18:10:31

Roland Schwarz wrote:
> Howard Hinnant wrote:
>> I swear (lays hand on backup disk) on my backup disk, all N2184 (and  
>> N2178 as I understand it) wants of C++ cancellation is to request that  
>> the target thread (whenever it gets around to it, if ever) throw a  
>> normal C++ exception, which the target thread is free to subsequently  
>> catch, swallow and digest.  :-)
> 
> To be honest. I did not yet had time to study N2184 and 2178.
> But if this is true, wouldn't this be in contradiction to pthread
> semantics? Wouldn't this users rather confuse even more?

Indeed, I think these are two very different things:

1) Request a thread cancelation.

  This is what in POSIX threads is called pthread_cancel(), and what you
  presumably mean by "t.raise(cancel_exception)".

2) Notify that a thread has been canceled.

  This is what would presumably result in a thread_canceled exception
  being thrown.

As far as I understand, the desired semantics here would be 'deferred',
i.e. 1) is really only a request, i.e. at the point this call returns
there is no guarantee that the cancellation has been terminated (or
even initialized).

Note that you suggested "t.raise(std::thread_canceled)", which sounds
misleading, since 'canceled' suggests this is raised at the point
where the cancelation is finished, not requested.

For that matter I don't really see the point in using an exception
to signal the 'cancel request' to the target thread, while the use
of an exception in 2) makes a lot of sense, since the main discussion
(as far as POSIX threads & C++ is concerned) is about the cleanup, i.e.
the missing stack unwinding semantics.

(Part of the discussion is about whether the exception can be
caught without being rethrown in handlers such as 'catch (...) {}',
or whether catch(...) should see thread_canceled at all, etc.)

Regards,
                Stefan

-- 
      ...ich hab' noch einen Koffer in Berlin...