> Hi,
>
> On Tue, 27 Nov 2007, Jan Hudec wrote:
>
>> On Tue, Nov 27, 2007 at 10:48:00 +0000, Johannes Schindelin wrote:
>> > On Mon, 26 Nov 2007, Shawn O. Pearce wrote:
>> > > [...]
>> > > Otherwise I think what you really want here is a libgit that you can
>> > > link into your process and that can efficiently inflate an object
>> > > on demand for you. Like the work Luiz was working on this past
>> > > summer for GSOC. Lots of downsides to that current tree though...
>> > > like die() kills the GUI...
>> >
>> > But then, die() calls die_routine, which you can override. And C++
>> has
>> > this funny exception mechanism which just begs to be used here. The
>> only
>> > thing you need to add is a way to flush all singletons like the object
>> > array.
>>
>> Unfortunately, exceptions won't really work. Why? Because to use
>> exceptions, you need to have an exception-safe code. That is the code
>> needs to free any allocated resources when it's aborted by exception.
>> And git code is not exceptions safe. Given the lack of destructors in C,
>> it means registering all resource allocation in some kind of pool, so
>> they can be freed en masse in case of failure. Than you can also use
>> longjmp for die (for C they really behave the same).
>
> Sorry, I just assumed that you can read my mind (or alternatively remember
> what I suggested a few months ago, namely to "override" xmalloc(),
> xcalloc(), xrealloc() and xfree() (probably you need to create the
> latter)).
That sounds like the easiest (but not necessarily easy) direction towards
the goal. Thread-local or global (I don't think git is currently reentrant
anyway) would do. Also filehanles would have to be taken care of and
everything checked for using malloc, calloc, strdup and other libc
functions directly.
Than die could longjmp out to a specified buffer and could be safely
overriden to throw exception for C++ apps.
--
- Jan Hudec <bulb@xxxxxx>
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
