From: Alexandre Julliard Subject: Re: [PATCH] ntdll: Add SIGQUIT to server block set. Message-Id: <875z8gtnlg.fsf@wine> Date: Mon, 14 Sep 2020 16:55:07 +0200 In-Reply-To: <2f5d1926-126a-6801-6d80-8acc824e3e5c@codeweavers.com> (Paul Gofman's message of "Mon, 14 Sep 2020 17:21:37 +0300") References: <20200910234104.1216168-1-pgofman@codeweavers.com> <87bli8tsuz.fsf@wine> <2f5d1926-126a-6801-6d80-8acc824e3e5c@codeweavers.com> Paul Gofman writes: > On 9/14/20 16:01, Alexandre Julliard wrote: >> Paul Gofman writes: >> >>> Receiving SIGQUIT for forced thread termination may leave sync >>> objects (like virtual_mutex) locked. >> I suspect that this will only create a different class of deadlocks, >> with threads that can't be killed. Avoiding locks at process exit is >> probably safer. >> > The same problem may potentially happen if some thread is killed by > NtTerminateThread without relation to process exit. SIGQUIT is > probably not the only scenario, I guess we can potentially leave the > lock when processing, e. g., SEGFAULT during the lock and returning to > the syscall frame. Should not we try harder to avoid leaving ntdll.so > object locked? Maybe we can instead store the mutex pointer in thread > data and unlock it when leaving the ntdll.so scope due to SIGQUIT or > SEGFAULT? In general you can't unwind a mutex lock from an asynchronous signal. In theory of course we should never hang inside the kernel, but NtTerminateThread can just as well hang on a user space lock that can't be recovered from either, so it's not clear that it's a big issue in practice, outside of the process exit case. I'd suggest to fix that one first and see how far it gets us. -- Alexandre Julliard julliard@winehq.org