formalize waiting on multiple conditions

[vtjnash]

in poll_fd, we see one pattern for waiting on multiple conditions, I propose the following simplification based upon chaining of Condition variables:

wait( cond1 | (cond2 & cond3 & !cond4))

=> returns when either cond1 has occurred, or (both cond2 and cond3 have occurred, but cond4 has not occurred)

pseudo implementation:

immutable OrCondition <: Condition; a::Condition; b::Condition; end
immutable AndCondition <: Condition; a::Condition; b::Condition; end
immutable NotCondition <: Condition; a::Condition end
&(a::Condition, b::Condition) = OrCondition(a,b)
|(a::Condition, b::Condition) = AndCondition(a,b)
!(a::Condition) = NotCondition(a)
wait(::OrCondition) = return (wait(a)) or (wait(b)) based upon whichever one occurred
wait(::AndCondition) = return (wait(a), wait(b)) as a tuple

[JeffBezanson]

An alternative would be @or(f(), g()), which expands into the tasks needed to wait for the two operations in parallel. That way it is not tied to Conditions.

AndCondition can be replaced directly by (wait(a),wait(b)).

NotCondition is kind of interesting. It seems that to implement it, you'd need an extra Bool, and a task that waits for the condition and flips the Bool flag if it ever happens. However this does not work, since (1) notify will not necessarily notify all waiters, and (2) some other task might run before the flag-flipping task. This is just the same familiar race condition you get if you ever try to ask whether a condition happened (or if a RemoteRef has a value, etc.). If you want to know about a condition, you have to wait for it. So I'm not sure NotCondition is viable.

[vtjnash]

since our condition variables are edge-triggered, (wait(a), wait(b)) implies ordering (wait for a to occur, then wait for b to occur). I think @and would be equivalent to @sync begin; @async f(); @async g(); end. perhaps there should be an @inparallel; begin; f(); g(); end which is shorter to write, but expands to the same?

NotCondition seemed problematic even as I wrote it, but I figured I could try mentioning it anyways

[JeffBezanson]

You're right, we'd need @and as well.

[StefanKarpinski]

From an API perspective, using the boolean operators seems preferable to the macros.

[JeffBezanson]

I think the bottom line is that this has to be based on wait: you want a function waitfirst(a, b, c, ...) that calls wait on all its arguments in a parallel fashion. I don't think there is an appropriate type to define the operator on. But there could be a function that works like the suggested operators too, it just needs its own name.

[StefanKarpinski]

Would it be reasonable to have waitall and waitany? It seems unclear to me which of those wait(a,b,c,...) should do.

[vtjnash]

after further contemplation, I think the only reasonable implementation for the current design (of edge-triggering) is waitany (aka waitfirst). any other behavior implies state (e.g. level-triggering) which is not present in the current design

[amitmurthy]

I feel wait(a,b,c,...) or wait([a,b,c,...]) should behave like a waitany and return the object that was triggered. The objects can be any of the types that wait can accept, not just condition variables.

[malmaud]

In #12042, there was general support for taking inspiration from Go's select function.

[vtjnash]

agreed, this really needs to be a Channel / level-triggered condition queue to avoid missing events

[vtjnash]

We now have waitany and waitall for Tasks (and could be extended to other Events)