Re: [SPAM] - FW: RE: [c++-pthreads] Re: I'm Lost - Email found in subject

[Ted Baker <baker@xxxxxxxxxx>]

| ... Quite simply, I believe that is far too great a burden for the
| casual C++ user.  They are already struggling under the burden of
| a complicated language without us expecting them to understand
| intricacies of thread safety and lifetimes. ...

With this encouragement, I dare repeat what I suggested earlier,
i.e., that thread cancellation should just be omitted from the C++
thread API. 

It is very easy to say that anyone who uses thread cancellation
and C++ should take care to write code that is safe for cancellation
(whatever way it is defined to act in the new API).

It is another thing for the rank and file of ordinary C++
programmers to actually do this thing, reliably and consistently.

I see adding a standard C++ API with thread cancellation in the
same category as giving loaded guns to babies.  Say whatever you
want, but people will see this is as a blessing that cancellation
is a generally good thing, and that the gods of standards and
implementations have seen to making it safe for mortal use.

I can attest that I have been burned using Ada's equivalent to
thread cancellation (the "select...then...abort...end select;"
construct) to time out certain occasionally long-running
computations.  I missed some code that was unsafe to abort, and
then wasted a few days tracking down and intermittent error.
Rather than patch that one hole, and hope that I had not misssed
any others, I decided to do the conservative (and simpler) thing.
I switched over to a polling solution, inserting over-time checks
at a three key points in the computations.

Of course, polling won't help with cases where a thread is stuck
on a blocking system call, but then one does
have (dare I say it?)  pthread_kill().

If there is no standard API for thread cancellation, then
implementors are to quietly do that they think is the right thing
for cases where a user goes outside the standards, e.g., by mixing
C++ into a C application that uses thread cancellation (e.g., the
implementation could execute any C++ finalizers that are found
along the way during stack unrolling).  To make sure this does not
happen too easily, the implementor can provide a link-time or
run-time hack that must be invoked to allow this inter-mixture.
(For example, I guess that a little bit of header-file magic with
macros and symbol redefinition could cause the linker to reject
calls to pthread_cancel() from code that includes pthread.h when
they are linked with modules compiled using the C++ thread API
header.)

--Ted