I think the isTimedOut() in the generated code is redundant (xod-client 0.14.0).
// If the schedule is stale, clear timeout so that
// the node would not be marked dirty again in idle
idle() will set dirty if a schedule expires at the top of the transaction. isTimedOut() checks again, against the transaction start time. If it was expired in idle() it will always be expired here. And if it wasn’t expired in idle() it won’t be here.
If I’m thinking correctly, then idle() should
clearTimeout(nid); after marking a node dirty. And the isTimeOut() block goes away.
Either I didn’t understand you correctly, or you missed a small point. Let me show a synthetic unroll of a loop iteration for a particular node:
if node timed out:
# Here is important comment quote: Do not reset schedule here to give
# a chance for a node to get a reasonable result from `isTimedOut`
mark node dirty
if node is dirty:
# The small point:
# A user supplied `evaluate` could call `isTimedOut` to check the reason
# it was invoked. `isTimedOut` relies on data in `g_schedule`. If we’d clear
# timeout before, `isTimedOut` would always return `false`
if node was timed out since iteration start and it is not scheduled again:
clear timeout # we did everything what could depend on the current timeout
Does it make sense?
Ah, I see: to enable an evaulate() to detect the “reason” (input-dirty vs. scheduled). But, you overload the meaning of the saved schedule value. Thus, you have to re-check/clear after evaluate(). I would wish that was not an overloaded meaning, so that the if/clear code could be eliminated.
Yep. The small trick adds a portion of complexity but I have no idea how to achieve timeout-awareness without it and introducing more variables (consume more RAM). And until this is encapsulated detail of the runtime which doesn’t leak to the public node API I think it causes a little problem.
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.