Re: abort() calls

Jonathan Gilbert wrote:

> What about -- on platforms that support it -- allowing the project calling
> into the library to provide a jmp_buf to be longjmp()ed to instead of
> abort()ing, and replacing the abort() calls with calls to a wrapper
> function to pick between that and abort() if the user hasn't provided a
> jmp_buf (or the platform doesn't support it)?
>
> I don't know what Subversion's policy is on threading, but of course if
> multiple threads were to be involved, each thread would need its own
> jmp_buf, and either way, they would probably be best arranged in a stack,
> so that a routine could do this and not interfere with the caller's policy:
>
> if (setjmp(my_jmp_buf))
> {
> ...
> return; /* or abort(); or whatnot */
> }
>
> svn_push_emergency_exit_handler(my_jmp_buf);
>
> ... /* (calls to Subversion API here) */
>
> svn_pop_emergency_exit_handler();
>
> I suppose also the stack could be offloaded to the caller so that the
> execution stack could be used for the purpose, as in:
>
> if (setjmp(my_jmp_buf))
> {
> ...
> }
>
> callers_jmp_buf = svn_set_emergency_exit_handler(my_jmp_buf);
>
> ... /* (calls to Subversion API here) */
>
> svn_set_emergency_exit_handler(callers_jmp_buf);
>
> Most code would not need to use the feature, but anything integrating into
> a persistent user interface (like TortoiseSVN) would find it very useful.
>
> Just an idea.. :-)

I like that idea. And it could really avoid a lot of problems we now
have with all those abort() calls.

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