[jira] [Created] (ARROW-17173) [C++] Clarify lifecycle of a StopSource/StopToken

["Dewey Dunnington (Jira)" <ji...@apache.org>]

Dewey Dunnington created ARROW-17173:
----------------------------------------

             Summary: [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


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)