From: Paul Gofman <pgofman@codeweavers.com>
Subject: Re: [PATCH] ntdll: Add SIGQUIT to server block set.
Message-Id: <2f5d1926-126a-6801-6d80-8acc824e3e5c@codeweavers.com>
Date: Mon, 14 Sep 2020 17:21:37 +0300
In-Reply-To: <87bli8tsuz.fsf@wine>
References: <20200910234104.1216168-1-pgofman@codeweavers.com> <87bli8tsuz.fsf@wine>

On 9/14/20 16:01, Alexandre Julliard wrote:
> Paul Gofman <pgofman@codeweavers.com> 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?