westonpace commented on pull request #7179: URL: https://github.com/apache/arrow/pull/7179#issuecomment-745486624
> One possible limitation is that it doesn't seem easy for the consumer to know whether the producer will actually notice a cancellation request (some producers may be unable to?). Unless we expose a StopToken::Accept method that the producer calls to signal that it is able to react to cancellation requests. Correct, although I don't know of any cancellation framework that does support this. I'm not sure what the caller is supposed to do with the information that cancel is not supported. Potentially one could imagine that the user's "cancel" button is disabled if an operation cannot be cancelled but it's hard to imagine a non-cancelable operation making it all the way up to the user layer. For example, the moment a future is chained the resulting future will be cancellable (the second half of the chain might not run if cancelled at the first step). Any intermediate layer that looks at the stop token to prevent follow-up work will hide the underlying non-cancellability. If a producer doesn't support cancel (this could be very common, for example, there is typically no way to cancel an ongoing blocking I/O operation) then calling cancel can still just be a no-op. ---------------------------------------------------------------- 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]
