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

[Ted Baker]

OK. I now see from your example that intervened that you seem to
intend that functions that are asyn-cancel safe/unsafe have some
syntactic tag (like "const") so that the compiler can check them.
I was assuming that you would rely on the compiler to infer which
regions of code might be subject to asynch cancellation from the
embedded async_cancel{} and then work back the call trees to
infer which other functions might be unsafe.  It did not occur
to me that you would be willing to require users to go so far
in marking up their code.

--Ted

On Thu, Jan 08, 2004 at 07:11:55PM +0100, Alexander Terekhov wrote:
> 
> Ted Baker wrote:
> [...]
> > I thought you meant *compile* resolution of the overloading, so as
> > to generate different call contexts of the same function name.
> > Since your async_cancel{} code can have nested calls to arbitrary
> > (separately compiled) code, you can't do that without
>                        ^
>                        |
> async-cancel-safe -----+ (nested sync_cancel {} and no_cancel {}
> aside for a moment).
> 
> > interprocedural control flow analysis (across separately compiled
> > modules), which I don't believe gcc has any plans to do.  If you
> > are talking about dynamic (runtime) dispatching, then you are ...
> 
> I'm NOT talking about dynamic (runtime) dispatching. Think of
> const correctness.