Hi, On Fri, 16 Mar 2007, Marco Costalba wrote: > On 3/16/07, Nicolas Pitre <nico@xxxxxxx> wrote: > > On Fri, 16 Mar 2007, Marco Costalba wrote: > > > > > On 3/16/07, Marco Costalba <mcostalba@xxxxxxxxx> 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. I am sure I don't 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. It not only *moves* the issue somewhere else, but it also cleanly separates the issues. > 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. Why? First, it _is_ multi-threaded, since it calls external programs. That is even more than a thread. It is a process. Second, it _would_ be easy to just use the threads provided by Qt. > 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. We are talking about libgit. Which should make access to certain common functions on Git repositories easy. Nothing more than that. If you need to do that asynchronously, do _not_ fiddle with libgit. Just imagine what this would involve: you'd have to have timeouts (since there is _NO_ other way to find out when to return with empty hands, instead of blocking), which is _not_ portable. You'd soon be in the same _mess_ we are talking about with respect to exceptions. Also, you would make _all_ operations expensive, since they _would_ have to store state to be restartable. The common solution for your problem _is_ to use threads. And you have to admit that _only_ viewers would need asynchronous access anyway. I doubt that other tools -- which could take their advantage of a libgit -- would need such an access. Ciao, Dscho - 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