time for cyrus-imap v3.2?

[Howard Chu]

Bron Gondwana wrote:
> 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.

Not to sound like a broken record, but - if you were using named databases in LMDB
for all of these separate data structures, you would get atomic snapshots for free.

-- 
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/