Re: Libification project (SoC)

From: Marco Costalba <mcostalba@gmail.com>
Date: Mar 16, 2007, 21:07 UTC
Message-ID: <e5bfff550703161407u6afefae9u4a23cf1cb49125ce@mail.gmail.com>
In-Reply-To: <alpine.LFD.0.83.0703161454280.18328@xanadu.home>

On 3/16/07, Nicolas Pitre <nico@cam.org> wrote:

Show 16 quoted lines

> On Fri, 16 Mar 2007, Marco Costalba wrote:
>
> > On 3/16/07, Marco Costalba <mcostalba@gmail.com> wrote:
> > >
> > > *The most important thing for a libgit to be used by qgit is reentrancy*
> > >
> >
> > Another crtitical feature is that this call to git-rev-list-like
> > function MUST be non-blocking.
>
> I'm not sure I agree.
>
> The non-blockingness can be (and probably should be) handled at a higher
> level with your own threading facility of choice.  Making GIT
> restartable has the potential for making the core code much too complex.
>

The fact is that the solution is complex anyway, moving the complex code at higher level doesn't simplify the whole issue, it just *moves* the issue somewhere else.

BTW now qgit is single-threaded (as gitk), you suggest that linking with libgit it will involve to go on the multi threading side and I think you are right. But it will be not that easy.

Currently we have both single threaded GUI tools and blocking git commands and it works nicely not because it's simple but because the 'complex code' is hidden inside the OS process handling and scheduling stuff.

Linking with a synchronous libgit it means, roughly speaking, take the 'complex code' out from the OS and put somewhere in user space, or in libgit or in the user GUI tool linked with the library.

Now, it happens that Qt has a good multi thread support, but this is just incidental and of course cannot be taken as granted by a git library that aims to be broadly and possibly easily used.

Because we are just speaking (well, writing ;-) ) about a possible library I think we could take in account what would involve to foreseen a callback mechanism in the API, at least for the slowest ones.

    Marco