[
https://issues.apache.org/jira/browse/ARROW-17173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17607709#comment-17607709
]
Antoine Pitrou commented on ARROW-17173:
----------------------------------------
But I agree that the design of having {{StopToken}} tied to {{IOContext}} and
therefore to a filesystem instance is not ideal. Not sure how to solve this
without adding lots of explicit {{StopToken}} arguments everywhere.
cc [~lidavidm]
> [C++] Clarify lifecycle of a StopSource/StopToken
> -------------------------------------------------
>
> Key: ARROW-17173
> URL: https://issues.apache.org/jira/browse/ARROW-17173
> Project: Apache Arrow
> Issue Type: Improvement
> Components: C++
> Reporter: Dewey Dunnington
> Priority: Major
>
> In ARROW-11841 we ran into an issue where a single cancellable operation
> (i.e., {{SetSignalStopSource()}}/{{ResetSignalStopSource()}} was a poor fit:
> the {{StopToken}} must be assigned to an {{IOContext}} when a filesystem is
> created; however, the filesystem may be reused for more than one cancellable
> operation (e.g., reading a CSV). Following the instructions in the current
> API (in util/cancel.h) results in a situation the lifecycle of the filesystem
> must match the lifecycle of the {{StopSource}}, which can be difficult to
> program around.
> A related problem is that where we load Python and R Arrow libraries that
> link to the same .so. After ARROW-11841, R will have the ability to register
> signal handlers to interrupt Arrow operations, and users that load pyarrow
> via reticulate must be careful to disable it or they will get an error along
> the lines of "StopSource already set up".
> From a purely R-centric point of view, we could provide our own {{StopToken}}
> implementation if we were allowed to since R already implements the proper
> signal handler and the arrow R package implements the proper event loop to
> make this thread safe. Currently the {{StopToken}} is passed by value and
> thus a subclass is not an option. For R, anyway, this would eliminate any
> need to consider the lifecycle of another object.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
