labath wrote: The SIGURG thing confused me a bit. The commit message makes it sound like receiving a SIGINT does not interrupt a blocking syscall. This isn't true because, while the signal *callback* runs on a different thread, the signal *handler* (`static SignalHandler` in MainLoopPosix.cpp) runs on the thread chosen by the kernel (same as before), and it is installed without SA_RESTART, so it should interrupt syscalls. I think what's happening is (and the code comments allude to that) is that the syscall gets interrupted, but then the code checks some flags (which aren't set because we haven't called `DispatchInputInterrupt` yet), and goes back to sleep. The subsequent SIGURG yanks it out of that.
If that's true, I think this is a relatively elegant solution to that problem. Which isn't to say I don't have things to say about it: :p - I'm wondering if we could avoid grabbing another signal for this (SIGURG could in theory be used by some other part of the application). I think the same effect could be achieved by sending another SIGINT to the main thread (obviously, after we've restored the handler) -- and then setting a flag to ignore the next callback invocation. WDYT? - How sure are you that it will always be the main thread that's in the blocking syscall? If it isn't, then this trick will not work -- though this may not be a regression since linux at least, tends to pick the main thread for delivering SIGINTs. It kinda feels like this would be better done inside `ScriptInterpreterPythonImpl::Interrupt`, because that could be in a position to know which thread is running the python code. The problems with that are: - It's incompatible with the first idea - It requires a library (liblldb) to be mucking with signal handlers, which tends to be icky.. Unless we have the Interrupt functions return the thread (threads?) which should be interrupted by the top level code, which is also icky... I'm not insisting on any particular solution, but I'd like to hear what you think about what I've said. https://github.com/llvm/llvm-project/pull/195959 _______________________________________________ lldb-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
