On 10/5/24 13:35, Ilya Leoshkevich wrote:
How can we handle the long-running syscalls? Just waiting sounds unsatisfying. Sending a reserved host signal may alter the guest's behaviour if a syscall like pause() is interrupted. What do you think about SIGSTOP-ping the "in_syscall" threads? A quick experiment shows that it should be completely invisible to the guest - the following program continues to run after SIGSTOP/SIGCONT:#include <sys/syscall.h> #include <unistd.h> int main(void) { syscall(__NR_pause); };Hmm, no, that won't work: SIGSTOP would stop all threads. So I wonder if reserving a host signal for interrupting "in_syscall" threads would be an acceptable tradeoff?
Could work, yes. We already steal SIGRTMIN for guest abort (to distinguish from host abort), and remap guest __SIGRTMIN to host SIGRTMIN+1. Grabbing SIGRTMIN+1 should work ok, modulo the existing problem of presenting the guest with an incomplete set of signals.
I've wondered from time to time about multiplexing signals in this space, but I think that runs afoul of having a consistent mapping for interprocess signaling.
r~
