dcapwell commented on code in PR #17: URL: https://github.com/apache/cassandra-accord/pull/17#discussion_r1053704969
########## accord-core/src/main/java/accord/utils/async/AsyncResult.java: ########## @@ -0,0 +1,96 @@ +package accord.utils.async; + +import java.util.concurrent.Executor; +import java.util.function.BiConsumer; + +/** + * Handle for async computations that supports multiple listeners and registering + * listeners after the computation has started + */ +public interface AsyncResult<V> Review Comment: > Wdym more cas/volatile overhead? There should be no more overhead in this regard. If there is, it’s a mistake and we should fix it. We have a AsyncResult, we create a AsyncChain which listens to the result, we then produce a new AsyncResult which is a copy of the first one. If we used the AsyncResult directly we would avoid the extra overhead (listen + copying result); see extra last comment going over this more clearly. > Slightly different code performing the exact same work is code duplication? In this case its the same semantic work, but that's a similar argument to saying `Iterator` shouldn't have a `forEach` because `Stream` has a `forEach`, or that `Routables.foldl` and `Topology.foldl` should not both exist. Why is it a problem for `map` and `flatMap` to only exist in one type where as `forEach` and `fold` are allowed across multiple types? > and not having multiple hops today says nothing about the future? It does about the concern. If the concern is that we will have multiple hops, `AsyncChains` offers a way to lower this when we get this issue, but this has nothing to do with the majority of cases which only have a single hop. Why choose to impact the majority of cases because one day we may have a case that could choose to use a different API call? > If you want to do chaining of AsyncResult, it would probably be better to have Future implement AshncResult and convert to Future, since at this point you are not saving anything with the separate concept. From a user/contributor to this project, `AsyncResult` to me is just a `Future`. We are able to remove the cassandra dependency by taking ownership of our own future, which has its own benefit. If we rename `AsyncResult` to `Future`, I am cool with this... > Yep, there should only be two CAS, same as we would need to directly transform. One to register the callback on the old AsyncResult, and one to set the new AsyncResult outcome. In the case of `map` they are equal, never attempted to argue that there are more CAS in this regard. My comment about extra CAS was the new pattern of ``` private AsyncChain<Void> applyChain(SafeCommandStore safeStore, boolean canReschedule) ... return applyWithCorrectScope(safeStore.commandStore()).toChain(); // usage private AsyncResult<Void> applyWithCorrectScope(CommandStore unsafeStore) ... AsyncChain<Void> chain = super.applyChain(safeStore); result = AsyncResults.forChain(chain); ``` This pattern exists a few times in the Cassandra PR and are all the same: 1) We have a async operation, so have a `AsyncResult` 2) API forces `AsyncChain`, so "listen" to the result and return the chain 3) We want the result, so convert to `AsyncResult` This pattern is where my comment comes from, this pattern "could" return the original result, but because we expose Chains we now have 2 extra CAS (1 to listen, 1 to store the result). -- 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]
