[Imap-protocol] SELECT/EXAMINE clarification of UNSEEN

Bron Gondwana brong at fastmail.fm
Wed Nov 16 06:49:06 PST 2011




On Wednesday, November 16, 2011 4:43 PM, "Timo Sirainen" <tss at iki.fi> wrote:

> On Wed, 2011-11-16 at 15:35 +0100, Bron Gondwana wrote:

> >

> > On Wednesday, November 16, 2011 2:38 PM, "Timo Sirainen" <tss at 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.

>

> There's no gappyness.


That's not the model Mark was proposing, where you allocate a GUID under a mutex, but then the append can still abort for whatever reason.

If you're not doing that, my lockyness concerns don't apply.


> > 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

>

> The messages don't get a (G)UID until they are complete and being

> committed.


Fair enough. You still need ordering guarantees of the commits themselves though. How are you allocating GUIDs locklessly? Are they based on the order in which your writes actually happened by reading back?

Bron.
--
Bron Gondwana
brong at fastmail.fm




More information about the Imap-protocol mailing list