Re: [c++-pthreads] Re: thread-safety definition

[Jason Merrill <jason@xxxxxxxxxx>]

On Tue, 20 Jan 2004 08:14:42 -0500, Dave Butenhof <David.Butenhof@xxxxxx> wrote:

> We could require the language to perform some call stack analysis as part
> of deciding whether to deliver a cancel in the first place -- which goes
> along with my earlier "random speculation" that the C++ concept of 'cancel
> enabled' might be a dynamic property of the call stack rather than explicit
> API. I was thinking in terms of disabling cancel within a 'throw()'
> scope... but there might be other conditions. For example, we could disable
> inside either 'throw()' or any try with a catch(...) that doesn't
> rethrow... unless there's an INNER scope that allows throwing cancel AND
> with an explicit catch(cancel). So a nothrow destructor (regardless of
> whether all destructors were implicitly nothrow or not) could allow "local"
> cancellation by nesting a try{} catch(cancel) {}.
>
> (Sounds too complicated; but it's something to think about. ;-) )

I does sound too complicated.  In particular, whether or not a catch(...)
block rethrows is undecidable; aside from the halting problem, it could
call another function which rethrows.

However, some call stack analysis might be appropriate to determine whether
or not we're executing a destructor.

Jason