On Wed Jan 10 12:07:17 2024 +0000, Zebediah Figura wrote:
`read_reply_data` can now return failure. Shall we update its only
caller, `wait_reply`, to handle it? I meant to do that but accidentally forgot; fixed now.
The abandoned thread, detached from the server, is no longer forcibly
aborted and thus let loose to do whatever it wants as long as it doesn't involve a server call, and in case of abnormally terminated server, a SIGQUIT might not have even arrived. The commit message describes why I think this is fine. If the hangup was intentional, the thread will process SIGQUIT once it's ready; if it wasn't, letting the thread hang doesn't make things (much) worse in practice, i.e. the user is already going to have to manually kill a bunch of stuck Wine processes.
IMHO my problem isn't about actually hung (blocking) processes; they are doomed to get stuck anyway as you said.
My problem is processes that *continue* to do something externally visible without assistance from the server. A nontrivial portion of syscalls don't actually require the server to work; for example, NtWriteFile() can work with fd cache alone as long as it doesn't need to send completion to the server. Other syscalls that *do* contact server will just return `STATUS_THREAD_IS_TERMINATING`, which has ample possibility to confuse the app which won't voluntarily terminate by itself.
I think calling `raise(SIGQUIT);` just before returning `STATUS_THREAD_IS_TERMINATING` will fix all that, while still achieving your purpose. If the server has already sent SIGQUIT, this has virtually no effect; otherwise, the signal will be delievered once we unblock it later.