westonpace commented on pull request #7179: URL: https://github.com/apache/arrow/pull/7179#issuecomment-745031743
So for discussion & comparison's sake, I will point out that this approach is a little different than C#'s "unified" approach [1] and is more in line with Java's approach (minus Java's added complexity around "interrupts"). In the C# model the stop token is provided by the consumer which is a little counter-intuitive but it does have some advantages. An intermediate layer's only responsibility is to receive the cancellation token and pass it down to all lower layer calls. For example, consider some kind of intermediate parsing-aggregation layer. It makes multiple concurrent calls to load and parse a column of data. With the current approach it would have to keep track of several stop tokens, provide its own stop token (which it returns to the caller), listen to its stop token, and propagate any cancellation to all of the child stop tokens. This model also means that arrow-10182 will have to propagate cancellation up the callback chain. In other words, when a child future is cancelled, it should cancel the parent future that caused the child future to be created. This is the opposite direction that errors propagate. I'm certain it's something that can be done, but it adds more complexity. In the unified model all futures in the chain would be cancelled at once (since they share the same cancellation source) and there is no need to propagate. On the other hand, to play devil's advocate, the unified cancellation model can be confusing to the consumer. As I mentioned earlier, it is counter-intuitive for the consumer to provide the cancellation token. People are used to the idea of getting some kind of handle back from a long running operation that they cancel. [1] https://docs.microsoft.com/en-us/dotnet/standard/threading/cancellation-in-managed-threads ---------------------------------------------------------------- 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]
