[c++-pthreads] thread-safety definition

[Ted Baker]

On Thu, Jan 08, 2004 at 05:52:31PM +0100, Alexander Terekhov wrote:
> Ted Baker wrote:
> > 
> > > Heck, let's mandate to have async-cancel-safe strlen()-and-alike
> > > stuff "in-addition-to OR instead-of" async-cancel-unsafe stuff
> > > and simply use C++ function overloading to pick the right stuff
> > > (async_cancel_safe inside async_cancel{}), okay?
> > 
> > A joke?  (With nested calls and separate compilation you obviously
> > cannot tell what call is "inside" an async_cancel{}.)
> 
> It's pretty much like "const correctness" for member functions 
> but with "execution context" instead of "type of this" (and with 
> "async_cancel_safe"/"async_cancel {}" instead of "const"). 

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
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
adding runtime overhead to all calls, and could just as well *not*
use overloading; instead, you could just as well have one wrapper
function that is the C++ binding, and this wrapper function
dynamically decides whether to do the extra work of protecting
itself against async cancel, depending on the context implicit
parameter.

--Ted