At 11:21 PM 4/28/2007 -0700, Blair Zajac wrote:
>On Apr 28, 2007, at 8:55 PM, 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)?
>
>How does this interact with C++ code and exceptions?
As I understand it, as long as you're calling the Subversion API directly
there should be no problem because the Subversion code base is entirely C.
Memory leaks also should not be an issue because Subversion uses APR pools
to track allocations; clear the pool you passed in in the first place and
all stray allocated blocks will get cleaned up. Just don't longjmp() past
C++ structured error handling blocks. :-)
That said, I'm fairly certain Microsoft's implementation of longjmp() is
SEH-savvy. SEH in Windows is of course provided by the OS and not by the
language, and so it's not at all difficult to properly handle __finally
blocks and unwinding that in conjunction with the stack in a
language-agnostic manner. I'm not quite so confident that GCC's SEH would
integrate well with longjmp(); someone would have to give it a test. Also,
SEH aside, destruction of objects going out of scope probably won't happen
with either compiler. There's only so much longjmp() can do. :-)
So the rule of thumb is probably: It'll work fine as long as you setjmp()
as close as possible to the boundary to Subversion's API. Don't create a
situation where an object would have to be destructed as part of unwinding
the stack because it probably won't happen.
Jonathan Gilbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Apr 29 16:43:20 2007