[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Nmh-workers] Locking (specifically, sequences)
From: |
David Levine |
Subject: |
Re: [Nmh-workers] Locking (specifically, sequences) |
Date: |
Sun, 10 Mar 2013 22:11:05 -0400 |
Ken wrote:
> >> AFAICT, if you reread the sequences file, that will solve that
> >> problem. I cannot think of a scenario when it does not; can
> >> you think of one that doing that will fail?
> >
> >Not off hand, but I can't get beyond "merge conflict".
>
> Maybe you're thinking of it wrong.
>
> We have message N. For each sequence, there is 1 bit of
> information: is it on this sequence?
I think that answers it. We're limited in what we can
do with that 1 bit, and the bits are independent.
> Now think about nmh operations: do we ever get into a
> situation where one command wants to add a message to a
> sequence, and another command wants to _remove_ the same
> message from the same sequence? That's really the only
> possible "merge conflict" we're talking about here.
Even that doesn't bother me. All but the last command will
lose the race, which is what we always want.
David
- Re: [Nmh-workers] Locking (specifically, sequences), (continued)
- Re: [Nmh-workers] Locking (specifically, sequences), Lyndon Nerenberg, 2013/03/12
- Re: [Nmh-workers] Locking (specifically, sequences), Lyndon Nerenberg, 2013/03/11
- Re: [Nmh-workers] Locking (specifically, sequences), Ken Hornstein, 2013/03/11
- Re: [Nmh-workers] Locking (specifically, sequences), Lyndon Nerenberg, 2013/03/11
- Re: [Nmh-workers] Locking (specifically, sequences), Ralph Corderoy, 2013/03/10
- Re: [Nmh-workers] Locking (specifically, sequences), Ken Hornstein, 2013/03/10
Re: [Nmh-workers] Locking (specifically, sequences), David Levine, 2013/03/10
Re: [Nmh-workers] Locking (specifically, sequences), David Levine, 2013/03/10
Re: [Nmh-workers] Locking (specifically, sequences),
David Levine <=