50 lines
2.3 KiB
Plaintext
50 lines
2.3 KiB
Plaintext
MBOX-Line: From brong at fastmail.fm Wed Nov 16 06:35:38 2011
|
|
To: imap-protocol@u.washington.edu
|
|
From: Bron Gondwana <brong@fastmail.fm>
|
|
Date: Fri Jun 8 12:34:47 2018
|
|
Subject: [Imap-protocol] SELECT/EXAMINE clarification of UNSEEN
|
|
In-Reply-To: <C38AC38C-01C6-46FD-A102-9CD703FC2281@iki.fi>
|
|
References: <1321346922.6321.140660999083661@webmail.messagingengine.com>
|
|
<4EC268D1.7010404@aol.com>
|
|
<1321364880.3715.140660999182809@webmail.messagingengine.com>
|
|
<alpine.OSX.2.00.1111151258420.38075@hsinghsing.panda.com>
|
|
<20111115233902.GA1071@brong.net>
|
|
<alpine.OSX.2.00.1111151543580.38075@hsinghsing.panda.com>
|
|
<D454A5E5-BEDE-47E6-909B-2C90463835EE@iki.fi>
|
|
<alpine.OSX.2.00.1111151800340.38075@hsinghsing.panda.com>
|
|
<20111116052757.GB12266@brong.net>
|
|
<alpine.WNT.2.00.1111152130220.912@Shimo-Tomobiki.Panda.COM>
|
|
<20111116065154.GA4452@brong.net>
|
|
<C38AC38C-01C6-46FD-A102-9CD703FC2281@iki.fi>
|
|
Message-ID: <1321454138.23977.140660999695557@webmail.messagingengine.com>
|
|
|
|
|
|
|
|
On Wednesday, November 16, 2011 2:38 PM, "Timo Sirainen" <tss@iki.fi> wrote:
|
|
> Sounds like you're talking about your specific implementation, since I can't really think of why any of the above would be a problem or why there would be any need of blocking. I've actually thought of a way to create zero-lock-waits IMAP-compliant mailbox format on POSIX filesystems that do atomic writes with O_APPEND (practically all apparently), so I'm sure any blockers can be worked around.
|
|
|
|
Teah - allowing gappyness certainly offers some nice properties.
|
|
|
|
But, I don't see how you can allow reads to see the messages until they are fully committed and indexed and "durable" for whatever level of guarantee you require. And because of that, I don't see how you can allow writes without ordering
|
|
enforcement of "this commit is guaranteed to complete".
|
|
|
|
Consider:
|
|
|
|
* session A starts a write, gets GUID 101
|
|
* session B starts a write, gets GUID 102
|
|
* session B completes the write and return GUID 102 to its caller.
|
|
|
|
Suddenly session B is living in a world where 102 exists but 101 doesn't yet.
|
|
|
|
So you can't allow session B to return until session A is committed, or if you
|
|
do - you can't allow it to READ anything (or any client which has a shared idea
|
|
of the mailbox state from session B for that matter) - or it will get an
|
|
inconsistent read.
|
|
|
|
Bron.
|
|
--
|
|
Bron Gondwana
|
|
brong@fastmail.fm
|
|
|
|
|