time for cyrus-imap v3.2?

[Bron Gondwana]

On Thu, Nov 7, 2019, at 15:46, Anatoli via Cyrus-devel wrote:
> Bron,
> 
> Thanks for your detailed reply and the work the FM team is doing!
> 
> > This is not easy unfortunately with all the different datastructures,
> > because it means that everything else which takes a lock is going to
> > need to first take a global shared lock before it does anything else,
> > and that's going to have a performance and complexity impact on
> > everything - because you have to find them ALL or you might wind up
> > with lock inversions down the line.
> 
> One solution I see is to have a separate single lock, not even a lock
> per se, but a barrier. I.e. before every write operation

How does that maintain consistency? I guess you don't get skew between files, but you still have to do crash recovery on every file. There's no single place to put this either.

I think I still prefer the idea of a shared locks that wraps every single other lock, such that taking the snapshot pauses every attempt to start a new lock until it's done, so you always get a completely clean read equivalent to a clean shutdown.

Bron.
--
 Bron Gondwana, CEO, Fastmail Pty Ltd
 brong at fastmailteam.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.andrew.cmu.edu/pipermail/cyrus-devel/attachments/20191108/ab84794f/attachment.html>