Re: [c++-pthreads] cancellation points report failure

[Ted Baker <baker@xxxxxxxxxx>]

If I'm confused, enlighten me.

How are you going to implement this version of
read() that raises the exeption?

The only way I know is to create a wrapper for the C-language
read() function (or the corresponding system call trap), check the
return value and if it is negative, throw the exception.

If you are lucky in how the thread-safe version of the
C-language read() works it will already be a wrapper for the
system-call trap, that checks for pending cancelation
before returning.  If you are willing to go directly to the
trap, you can replace this code by code to throw your exception.
It means you will need to implement your binding in a non-portable
way, using the appropriate traps, rather than writing
wrappers for the already-standardized C-language functions.

If you are unlucky, the implementation of thread cancellation
will be done at the kernel level, and the check for pending
cancellation will be done beore return from the system
call trap.  In that case you will not get a chance to catch it
and turn it into an exception unless you are friendly with
the kernel maintainer.

--Ted

On Fri, Dec 19, 2003 at 04:34:21PM -0500, David Abrahams wrote:
> Ted Baker <baker@xxxxxxxxxx> writes:
> 
> > How do you propose to prevent cancelation occurring (i.e., the
> > thread starts executing the cleanup routines and then exits) if a
> > C++ library function uses an underlying C library call that is a
> > thread cancelation point?
> >
> > Are you figuring on redoing all the libraries to avoid calls
> > to such C functions?
> 
> One of us is very confused.  What you're talking about is the problem
> we have today.  IIUC, Nathan was suggesting that read() should report
> cancellation using the same means it uses to report failures to 'C'
> programs, IOW, not by throwing an exception.  Maybe I've
> misunderstood something?