Thanks for your work. I'm glad we've come to the same conclusion.
In my side, I've also removed the c->dirtylk lock. It solved the
deadlock problem, but I was still unsure it was the right thing to do.
I've tried to obtain more information from the Fossil authors,
but without success.
Since we b
On Mar 22, 2012, at 12:57 PM, Richard Miller <9f...@hamnavoe.com> wrote:
> Thanks to detective work by Rod at hemiola and David du Colombier,
> I've been able to find & fix the long-standing deadlock in fossil's
> snapshot code.
>
> Patch is fossil-snap-deadlock.
Kudos to you all!!
G.
Thanks to detective work by Rod at hemiola and David du Colombier,
I've been able to find & fix the long-standing deadlock in fossil's
snapshot code.
The problem is the lock c->dirtylk, which prevents any thread from
dirtying new blocks while flushThread is writing old dirty blocks to
disk. Deadl
On Thu Sep 15 10:31:09 EDT 2011, eeke...@fastmail.fm wrote:
> On Thu, 08 Sep 2011 13:48:23 +0100 r...@hemiola.co.uk wrote:
>
> > I can easily get fossil to deadlock. It would be great if anyone
> > with fossil internals expertise could comment.
> >
> Every now and then someone studies fossil, ha
On Thu, 08 Sep 2011 13:48:23 +0100
r...@hemiola.co.uk wrote:
> I can easily get fossil to deadlock. It would be great if anyone with
> fossil internals expertise could comment.
Every now and then someone studies fossil, having the belief that if only it
were understood it could be made to work
I can easily get fossil to deadlock. It would be great if anyone with
fossil internals expertise could comment. As far as I can it tell from
a stack dump it usually goes like:
The snapshot thread has called cacheFlush with "wait" set to 1 to
ensure all blocks are flushed to disk before continuing
