maybe_like_this.erl

+wait_loop(Parent, Timeout, State) ->
    % State transitions
    % unset -> (updated | timeout | waiting)
    % updated -> (updated | unset)
    % timeout -> (unset | updated)
    % waiting -> unset
    receive
        db_updated when State == waiting ->
            Parent ! updated,
            wait_loop(Parent, Timeout, unset);
        db_updated when State == unset orelse State == updated ->
            wait_loop(Parent, Timeout, updated);
        get_state when State == unset ->
            wait_loop(Parent, Timeout, waiting);
        get_state ->
            Parent ! State,
            wait_loop(Parent, Timeout, unset);
        done ->
            ok
    after Timeout ->
        case State of
            waiting ->
                Parent ! timeout;
            unset ->
                wait_loop(Parent, Timeout, timeout)
        end
     end.

Paul,

Thanks I basically used this. I think you missed one edge case. If you hit the second db_updated clause in the unset state, but arrived there from having already seen db_updated in the waiting state then after you drain the mailbox you leave the state as updated yet you've already notified the Parent.

I think the version I just pushed handles this case, note I tweaked the state machine accordingly.

Bob

But the assumption is that you're not leaving db_udpated messages in the mailbox. You could add a step to drain them with a 0 timeout, but you don't want to accidentally miss them. This version is wrong with the timeouts but I think its right for this db_updated message handling.

draining them is what I'm doing here -

cloudant/fabric@20ed391#L0R294

I think I've also got the Timeout clause right -

cloudant/fabric@20ed391#L0R309

this agrees with your newest gist, non?

oops, sorry, no, - cloudant/fabric@822e2f6

is the newest

I don't think you want that drain in there. The point of looping through the db updated messages is so that your mail box should never have a backlog so there shouldn't be anything to drain.

As to the Timeout clause, there should be no timeout state. That changse the behavior of the keep sending changes loop because its possible to timeout directly after you finish an update. The timeout should only be triggered after the get_state message as waited for Timeout seconds, not if there was more than Timeout seconds before the get_state message with no db_updated message. Its slight and subtle, but I bet it'd at least break tests.

Agree about the timeout (typo there), not sure I agree about the drain but I'll defer to your judgement there. Let me push a PR so we can get more eyeballs on it

cloudant/fabric@cca4750