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.