[
https://issues.apache.org/jira/browse/ARROW-16086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17516127#comment-17516127
]
David Li commented on ARROW-16086:
----------------------------------
What is FlightStreamHandler here? That's not part of PyArrow.
When I try, it looks like the main thread is stuck in gRPC. Unfortunately, I
don't think we can do much about that. While the Python interpreter does appear
handle the signal (from looking in a debugger), it can't pass it to the
application until control returns to the interpreter thread. And that isn't
happening because gRPC appears to call epoll_wait in a loop, ignoring
interrupts:
[https://github.com/grpc/grpc/blob/5fc3ff82032d0ebc4bf252a170ebe66aacf9ed9d/src/core/lib/iomgr/ev_epoll1_linux.cc#L723-L727]
We might be able to override the signal handler in C++ or Cython and forcibly
cancel the gRPC call…it might be better, though, for the application to just
use a background thread, if you want to do anything besides cancel the gRPC
call. (Also doing so would be very tricky, and gRPC is explicitly not
signal-safe, IIRC.)
> [Python] Calls to do_get ignore Python signal handlers
> ------------------------------------------------------
>
> Key: ARROW-16086
> URL: https://issues.apache.org/jira/browse/ARROW-16086
> Project: Apache Arrow
> Issue Type: Bug
> Components: FlightRPC, Python
> Reporter: Alex Bergeron
> Priority: Major
>
> Similar to ARROW-15106 but observed from the client, not the server.
> The Python Flight client blocks the thread and ignores signal handlers. This
> makes it impossible for the client to handle the signal handler and cancel
> the query before it has returned a FlightStreamHandler.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
