belliottsmith commented on code in PR #10:
URL: https://github.com/apache/cassandra-accord/pull/10#discussion_r990278797
##########
accord-core/src/main/java/accord/messages/Apply.java:
##########
@@ -54,15 +63,59 @@ public Apply(Node.Id to, Topologies topologies, TxnId
txnId, Txn txn, Key homeKe
this.result = result;
}
+ @VisibleForImplementation
+ public Apply(Keys scope, long waitForEpoch, TxnId txnId, Txn txn, Key
homeKey, Timestamp executeAt, Deps deps, Writes writes, Result result)
+ {
+ super(scope, waitForEpoch);
+ this.txnId = txnId;
+ this.txn = txn;
+ this.homeKey = homeKey;
+ this.executeAt = executeAt;
+ this.deps = deps;
+ this.writes = writes;
+ this.result = result;
+ }
+
+ static Future<Void> waitAndReduce(Future<Void> left, Future<Void> right)
Review Comment:
I am genuinely struggling to see it. What class of erroneous completions are
we avoiding? If maybeExecute does the wrong thing, why would it do the right
thing with a Future? Usually we aim to defend against erroneous use by external
code, not code we have control over - once we distrust ourselves all bets are
off, and compiler assistance here seems very weak.
Is it that you think the returning of an object somehow ensures semantic
scope, or that composition methods available to Future somehow make it easier
to guarantee correct completion?
If it’s that you may unintentionally complete a callback more than once (eg
with exceptional completion), this can be guarded against where we perceive a
risk of it with a single cheap encapsulating object, as discussed.
if it’s that you are concerned that a higher method (maybeExecute) may
accidentally invoke a callback even after it has passed ownership to a lower
method (apply), this can also be cheaply guarded against (by eg nulling out the
local parameter when you pass control) - but it’s also not very hard to simply
verify it by code inspection. This is a very weak class of problem IMO, and
does not justify the additional costs or machinery to me.
If it’s guarding against literally doing the wrong thing, I just don’t see
how a Future prevents a programmer error.
Can you give me an example of the kind of erroneous completion you imagine,
that a Future would prevent?
--
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.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
