[Imap-protocol] SELECT/EXAMINE clarification of UNSEEN
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
> 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