stevedlawrence commented on a change in pull request #473:
URL: https://github.com/apache/incubator-daffodil/pull/473#discussion_r562150651
##########
File path:
daffodil-runtime1-unparser/src/main/scala/org/apache/daffodil/processors/unparsers/ExpressionEvaluatingUnparsers.scala
##########
@@ -77,30 +76,52 @@ final class SetVariableUnparser(
}
+final class NewVariableInstanceSuspendableExpression(
+ override val expr: CompiledExpression[AnyRef],
+ override val rd: VariableRuntimeData)
+ extends SuspendableExpression {
+
+ override protected def processExpressionResult(ustate: UState, v:
DataValuePrimitive): Unit = {
+ ustate.variableMap.newVariableInstance(rd, v)
+ }
+
+ override protected def maybeKnownLengthInBits(ustate: UState) = MaybeULong(0)
+}
+
Review comment:
Thinking more on this, I think there's maybe some other complexities
related to variables, and doesn't even include NVI.
Imagine we having a variable with a constant static default, and then a
setVariable to set that variable but that must suspend due to a forward
lookahead. Now if an an element tries to read that variable, it must also
suspend until that setVariable completes. Something to consider with this is
that setVariable suspension is working on a cloned ustate. So the cloned ustate
must do a shallow copy of the variable map so that when it does modify the
variable map, other suspensions will see that change. I think this may be how
it works, but worth having some tests to consider.
But also note that since this is a shallow copy, it means other
suspensions/parsers could modify this variable map, and could maybe potentially
affect the suspension once it unsuspends? Maybe something like this:
* variable1 defaultValue = 1
* variable2 defaultValue = 2
* setVariable variable1, value = /forward/path/forcing/suspension + variable2
* setVariable variable2, value = 3
So setVariable variable1 must suspend. Then setVariable varible2 changes the
value of variable2 to 3. Then at some point when setVariable variable1
unsuspends, it gets the value of 3 for variable2 (assuming shallow variable map
copy in the ustate clone). The correct result is setVariable2 should cause an
SDE because setVariable variable1 should have read variable2. So this too has
this order dependency stuff going on and doesn't involve NVI. I think this is
basically the same thing as my previous scenario, but doesn't use NVI.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
