On Tue, 16 Jul 2003, Timo Sirainen wrote:
> I'm wondering if there's any problems with creating a message store that
> doesn't support atomic changing of multiple message flags. I don't think
> IMAP spec itself requires it, but are there any clients relying on this?
> If I did it, would it badly break some things? Or in general, is it a
> bad idea?

I'm not adamant on atomicity, although I think that it is desirable.
FLAGS are always subject to timing races no matter what you do.

Your example of:

> S1: * 1 (FLAGS (Junk))
> C1: 1 STORE 1 FLAGS (NotJunk)
>
> C2: 2 FETCH 1 FLAGS
> S2: * 1 (FLAGS (Junk NotJunk))

is a timing race since a later FETCH will return (Junk).

One way to avoid this is to make the flag list be a single token.  For
example, represent the flags as bit vectors which are updated in a single
write operation.  The system flags are 6 bits, and if you allow up to 26
keyword flags you can fit the entire thing in a 32-bit word.

This gives you atomicity without having to worry about these cases.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Reply via email to