MBOX-Line: From brong at fastmail.fm  Wed Nov 16 06:49:06 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: <1321454625.21919.548.camel@hurina>
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>
	<1321454138.23977.140660999695557@webmail.messagingengine.com>
	<1321454625.21919.548.camel@hurina>
Message-ID: <1321454946.28208.140660999703561@webmail.messagingengine.com>



On Wednesday, November 16, 2011 4:43 PM, "Timo Sirainen" <tss@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@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@fastmail.fm


