Re: abort() calls

Jonathan Gilbert wrote:
> At 09:34 PM 4/28/2007 -0600, Joseph Galbraith wrote:
>> A better alternative, in my opinion, would be to establish a
>> subversion function, something like:
>>
>> typedef void (*PFN_abort)();
>> void svn_set_abort_function(PFN_abort pfnAbort);
>>
>> The abort function would default to the standard abort, but
>> TSVN could call and set the abort function to a function that
>> throws an exception caught back at the original call site
>> in TSVN.
>
> Aha. I guess our e-mails crossed tracks :-) Actual structured error
> handling would work, but setjmp/longjmp is more general and can be used by
> C clients.
>
>> The only problem with this is that we'll leak any resources
>> allocated by TSVN during the function that triggered the abort,
>> but I don't see a good way around that...
>
> Don't APR pools take care of this automatically? I mean, the garbage might
> not be collected immediately, but it will eventually get cleaned out, as
> long as the exception handler/longjmp target doesn't bypass the cleanup
> that is mandatory when integrating with a long-running process.

If there's any chance that the apr pools can clean up something, then
the subversion lib should return an error and not call abort() at all.
Because that's a situation which I would consider as manageable, and
such situations should never call abort(). IMHO, abort() should only be
used as the absolutely last resort, if really there's absolutely *no*
other way to recover.

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org