concrete library-code example

[David Abrahams]

Dave Butenhof <David.Butenhof at hp.com> writes:

>>Here is a more-or-less concrete example, for discussion purposes.
>> It's meant as a generic example of code written according to the
>> existing contract offered by C libraries.
>>  
>>
> Correction: "... offered by C libraries that support POSIX
> 1003.1b-1993 or earlier."

I think Nathan meant what he said.  You seem to be viewing this in
terms of some POSIX standard, but I'm pretty sure even most good C
programmers write code without giving POSIX a second thought... even
thread-safe code.
 
>>  int affect_world(struct state* s)
>>  {
>>    int result;
>>    violate_invariants_or_claim_resources(s);
>>    result = c_function_or_system_call(s->member);
>>    if (result < 0) {
>>      clean_up(s, result);
>>      return result;
>>    }
>>    act_on_result(s, result);
>>    restore_invariants_and_release_resources(s);
>>    return 0;
>>  }
>>
>> This pattern is extremely common in both C and C++ libraries.  If
>> read() were to throw (or to "just ... not return"), the program
>> state would be corrupted.  A redefinition of
>> c_function_or_system_call semantics that breaks this code breaks
>> many thousands of existing thread-safe C and C++ libraries.
>>  
>>
> If this code exists in a pure ANSI C/POSIX application using threads,
> and if the thread running this code can be cancelled, then the
> implementation of this function is broken because IT (not the
> implementation, nor the cancellation) corrupts program state.

Again, you're missing our point.  We'd like to keep working
(non-POSIX) thread-safe code working when used in a POSIX environment,
without getting into a detailed review of every line of code.  Adding
exception-safety to an existing codebase is a nontrivial exercise, and
that's essentially what the current binding requires of people who
want to use code not written with POSIX in mind.

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