[Imap-protocol] SELECT/EXAMINE clarification of UNSEEN

Timo Sirainen tss at iki.fi
Wed Nov 16 04:38:15 PST 2011


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.


More information about the Imap-protocol mailing list