Re: [boost] Re: Draft of generation 2 thread class

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-01-19 12:36:11

----- Original Message -----
From: "bill_kempf" <williamkempf_at_[hidden]>

> > either. Even if people behave the way you like and keep the object
> off the
> > heap, there's no reason they can't touch it across threads. This is
> a simple
> > case where it costs nothing to specify a more robust implementation.
>
> It's not very controversial.  As I stated in another thread I just
> want some discussion about whether such usage can just lead to other
> errors/abuses by the user and whether there's any valid reason for
> using the technique in the first place.  The specification isn't more
> robust if it leads to other errors/abuses with out adding any actual
> benefit.

Okay, maybe I should think about this. Turning off cancellation just lets
you call cancellation points without causing an exception. The only reason I
can think of to do this is to ensure an exception guarantee for an
operation. The only reason I can think of to give the object a lifetime
which is not synchronized with the heap would be so that cancellation might
be turned off or on in the middle of an operation. Okay, the scenario goes
like this: you have a long-running operation which must provide the strong
guarantee. During the first part of the operation, it's okay to throw an
exception, because the original data is still recoverable. As soon as the
original data is first modified, the operation must run successfully to
completion, so you have to turn off cancellation. Cancellation needs to be
turned off in an inner loop and remain off until the operation completes.

Not hugely compelling, but plausible IMO.

-Dave