MBOX-Line: From tss at iki.fi  Wed Nov 16 04:38:15 2011
To: imap-protocol@u.washington.edu
From: Timo Sirainen <tss@iki.fi>
Date: Fri Jun  8 12:34:47 2018
Subject: [Imap-protocol] SELECT/EXAMINE clarification of UNSEEN
In-Reply-To: <20111116065154.GA4452@brong.net>
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>
Message-ID: <C38AC38C-01C6-46FD-A102-9CD703FC2281@iki.fi>

On 16.11.2011, at 8.51, Bron Gondwana wrote:

> On Tue, Nov 15, 2011 at 10:10:32PM -0800, Mark Crispin wrote:
>> On Wed, 16 Nov 2011, Bron Gondwana wrote:
>>> The other problems with strict ascendency is that it requires a global lock
>>> for the duration of any append, over whatever scope you require the
>>> ascendency in.  As you expand out from a single mailbox to the scope of an
>>> entire user, you expand the scope of that global lock.
>> 
>> Not necessarily. If the GUID is expanded to a uint64 then there's no
>> reason why the GUID assignment can't be simply:
>> 	<acquire mutex>
>> 	guid = ++lastguid;
>> 	<release mutex>
>> You don't care if the GUID space is holey; and with a uint64 you don't
>> even care if you end up losing some.
> 
> No, it's not that easy.  You need every view before to not include it,
> and every view afterwards to include it.
> 
>> There are even some systems where ++ is atomic (yes, even if multicore)
>> and you don't need the mutex.
> 
> That's cheap - making sure you never return these out of order is not.
> 
>> The real issue is MULTIAPPEND and its interaction with UIDPLUS.
>> Fortunately, you don't have to assign UIDs as messages are uploaded; you
>> can defer that until the uploads are completed. Since you now know how
>> many messages you are adding, you can claim an entire range of GUIDs via
>> 	<acquire guid mutex>
>> 	guid = lastguid += nappends;
>> 	<release guid mutex>
>> Then assign the already-claimed GUIDs at leisure while checking in the
>> append.
> 
> Only by blocking all reads while this is happening.

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.
