[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: abort() calls

From: Stefan Küng <tortoisesvn_at_gmail.com>
Date: 2007-04-29 09:22:08 CEST

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.


   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
Received on Sun Apr 29 09:22:26 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.