belliottsmith commented on code in PR #10:
URL: https://github.com/apache/cassandra-accord/pull/10#discussion_r990680958
##########
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:
Could you link me to the code you're referring to that _requires_ a `Future`
in C*?
This sort of speaks to my concerns, though: once `Future` gets its hooks in,
it turns up everywhere, and it is hard to escape. I do not want to bake it into
more APIs than necessary.
The paradigm of handling something _once the work is in-flight_ is
inherently costlier than a callback that can be declared before work begins, as
there is no concurrency to deal with in the latter case.
If we do end up using `Future` did you not see that I had implemented a
lightweight future upthread that also reduces allocations? But it permits at
most one listener, and expects single-threaded access by the producer and
consumer (they may run concurrently though).
> That should save more bytes on heap and cas operations overall than using
callbacks in apply
I think it is impossible for a `Future` approach to be lighter weight than a
callback approach.
> I think we need to agree to disagree and find a compromise though
That would be ideal, but it might not be possible. Let's certainly try, but
conflicting styles going through a library like this, and its integration with
Cassandra, can cause problems. Like I've said before, we can translate _to_ a
`Future` cheaply, but cannot save the cost once it is there, and `Future`
infects APIs and spreads (as you have indicated above). So, if we have to
choose, we should opt for the one that imposes its opinions least broadly. If
anything, this conversation has made me much more strongly opposed to their use
here than I was previously.
--
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]
