Python bindings behave poorly with long-running C++ calls
This is a a follow-on to issue #1491 (closed). The generic problem is that Python wants to handle interrupt behaviour like ^C in its own way. To that end, it installs its own signal handlers, and rather than interrupting a long running native C++ call it will catch the signal and then not run a handler until the C++ call returns and Python is once again in control. This means that ADIOS2 calls that can block for long periods of time (which are not uncommon in staging) are essentially uninterruptible and difficult to kill, perhaps requiring a "kill -9" on Linux or its equivalent. While #1491 (closed) was about SST reader-side open behaviour, the same thing can occur in any staging method whose reader-side doesn't time-out, where writer-side requires a rendezvous on open (RendezvousReaderCount>=1 in SST, where BeginStep can block indefinitely, where writer Close() must block until data is drained, etc. One approach to addressing this would be to modify the Python bindings to use a small timeout on things like reader-side Open(), then calling Open() in a Python-level loop until it succeeds or reaches the longer timeout value. This would allow a ^C to interrupt and Python to handle it. However, this technique is not applicable to other situations (writer-side Open(), Close() blocking, etc.). So the broader problem might require a different approach.