## Execution order of handlers in rescala

philomat
Erstie
Beiträge: 17
Registriert: 28. Mär 2011 14:50

### Execution order of handlers in rescala

Hi,

as it is stated in the slides the execution order of handlers that are attached to an event is non deterministic.
However if I recall correctly in the "Reactive Programming Exam" there were code examples like the following and we should figure out what value a certain variable would have after an event is fired:

Code: Alles auswählen

val e = new ImperativeEvent[(Int, String)]()
val b = new ImperativeEvent[Int]
var c = Var(0)
val d = Var(1)
b += (x => {
// handler 3
if(c.getVal == 1) c = Var(3)
else if(c.getVal == 2) c = Var(4)
println(x) })
e += (x => { // handler 1
c = Var(1)
println(x._1)
println(x._2)
b(1)
})
e += (x => { // handler 2
c = Var(2)
println(x._2)
println(x._1)
})
e((2, "Has"))
So in my example the value of c after e fired depends on the execution order:
case 1: it is 2 if handler1 fires first, handler3 second, handler 2 last
case 2: it is 3 if handler2 fires first, handler1 second, handler 3 last
case 3: it is 4 if handler1 fires first, handler2 second, handler 3 last

Is case 1 even possible? I mean will all handlers of e be executed before the handlers of b are?

Also I wonder about the execution order of two Signals that depend on the same event:
val a = Var(0)
s1 = Signal { a() }
s2 = Signal { a() }

imaier
Mausschubser
Beiträge: 61
Registriert: 21. Okt 2013 21:27

### Re: Execution order of handlers in rescala

As I mentioned in my post in the other reactive programming thread a minute ago, the kind of exercises you refer to are not very relevant for the exam. For all intents and purposes, you should consider the order of evaluation of two callbacks or signals on the same level (as in your last example) as undefined. Note that this does not mean that evaluation order is necessarily non-deterministic. By leaving something undefined in a framework such as REScala, you just reserve the right to change something (in this case evaluation order) later.

Cheers,
Ingo