[GitHub] [tvm] areusch edited a comment on pull request #6953: Add retry to sockets on EINTR error

[GitBox <gi...@apache.org>]

areusch edited a comment on pull request #6953:
URL: https://github.com/apache/tvm/pull/6953#issuecomment-738916059


   @tqchen okay, i've iterated on this with @rkimball and it's a little more complex. I was previously working on this problem when i was trying to make TVM RPC server run GDB. To do that, I installed a custom SIGINT handler in Python which only raised KeyboardInterrupt if GDB had died. 
   
   it turns out this all boils down to `siginterrupt()`, which Python implicitly calls when you set a custom signal handler and also exposes to Python programs as `signal.siginterrupt`. I was able to reproduce the behavior I saw in @rkimball's demo by adding this code to main():
   ```
   if (siginterrupt(SIGINT, 1) == -1) {
     perror("siginterrupt");
   }
   ```
   
   finally, the root of the problem: why does Python care about `EINTR` and `siginterrupt`? See [PEP 475](https://www.python.org/dev/peps/pep-0475/), which explains that basically handling is specific to even the particular Python code that's running on top of TVM. Python provides a callback function, `PyErr_CheckSignals`, and C extensions are supposed to invoke that function if `EINTR` is seen to decide whether to return. This is how Ctrl+C is handled in Python when a C extension is blocked in a syscall. To handle this properly within `libtvm.so` then, we need to provide some generic e.g. PackedFunc callback that frontends can set to define the `EINTR` behavior. This didn't seem worth it when I was just trying to run GDB on an RPC server, but it does now. Thoughts?


----------------------------------------------------------------
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:
users@infra.apache.org