concrete library-code example

[David Abrahams]

Jason Merrill <jason at redhat.com> writes:

> On Wed, 24 Dec 2003 22:42:19 -0800, Nathan Myers <ncm at cantrip.org> wrote:
>
>> On Wed, Dec 24, 2003 at 11:55:59PM -0500, Jason Merrill wrote:
>
>>> This is not cancellation-safe C under the current POSIX standard, if
>>> c_function_or_system_call is a cancellation point.  If it is, cleanups
>>> are run and the thread is terminated.  To be truly thread-safe, the
>>> user must use pthread_cleanup_push/pop so that the resources are
>>> released on  cancellation.
>>
>> I think that is what I said.  It was thread-safe code until the 
>> semantics of calls it uses changed without changing the names.  
>> What was good code is now broken, in a POSIX C thread-cancellation 
>> environment.  
>
> In what sense was it ever thread-safe?  It was fine for non-threaded code,
> but has always been broken in a POSIX threads environment.

Are any threading environments other than POSIX worthy of
consideration here?  If not, anything that's not thread-safe under
POSIX is, as you say, not thread-safe period.  

Otherwise, POSIX is breaking thread-safe code by introducing the
possibility of control flow (unwinding) that can't be anticipated
without knowledge of POSIX itself.  The real-world problems that
breakage introduces for plain C are somewhat minimized by the fact
that C code has to know something about how to register cleanups in
order to get any unanticipated control flow other than termination.
Still, unanticipated termination can leak important system resources
and cause other difficult-to-diagnose problems.  For C++, it's a much
more serious problem because the binding wants to run destructors, and
you don't need special knowledge of POSIX in order to write a
destructor.

>>> Implementing cancellation by throwing an exception has no effect on
>>> the thread-safety of this code.

Obviously that depends on how you define "thread safe".  Don't you
think defining it in terms of the POSIX standard is, in this case at
least, a bit circular?  It's a great way to close off certain parts of
the discussion, but it doesn't seem to provide us with any power to
think about the problems.

> Currently, the C++ binding is the C binding, so your example is broken
> under C++ as well.  And it would seem rather odd for the C++ binding to go
> to great lengths to accommodate code which is broken under C, when C++
> already provides a simple way to express cleanups.  C++ code doesn't need
> to mess with pthread_cleanup_push; it can just use destructors.

You say that like it's a *good* thing ;-)

I'm being slightly facetious here, but having destructors run
automatically under thread-cancellation is a double-edged sword if the
code's author was unable to anticipate the possibility of an
exception.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com