bug#25875: 26.0.50; Hang logging out of MS-Windows

[Ken Brown <kbrown@cornell.edu>]

On 2/26/2017 1:25 PM, Eli Zaretskii wrote:
>> Cc: 25875@debbugs.gnu.org
>> From: Ken Brown <kbrown@cornell.edu>
>> Date: Sun, 26 Feb 2017 13:04:18 -0500
>>
>> The problem might be that 1000 sec is too long for the input thread to sleep.  I chose that number arbitrarily, not realizing that the main thread could get stuck waiting for the input thread.  What about something like this?
>>
>> --- a/src/w32fns.c
>> +++ b/src/w32fns.c
>> @@ -4801,8 +4801,10 @@ w32_wnd_proc (HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
>>
>>      case WM_ENDSESSION:
>>        my_post_msg (&wmsg, hwnd, msg, wParam, lParam);
>> -      /* If we return, the process will be terminated immediately.  */
>> -      sleep (1000);
>> +      /* Allow time for Emacs to attempt an orderly shutdown.  If we
>> +        return, the process will be terminated immediately.  */
>> +      sleep (5);
>> +      return 0;
>>
>>      case WM_WINDOWPOSCHANGING:
>>        /* Don't restrict the sizing of any kind of frames.  If the window
>>
>> With this change, I think Emacs will be killed in at most 5 seconds no matter what state it is in.  But
>> I can't test this because I don't know how to reproduce Richard's problem.
>
> I think the problem in this particular scenario is not that the input
> thread sleeps too long, it's that whenever it finishes sleeping and
> returns, Emacs will be killed, so the WM_ENDSESSION message that was
> posted to the main thread will never have a chance to be processed,
> and thus orderly shutdown will never happen.
>
> That is why I thought about using SendMessageTimeout in the main
> thread: what we really want is to cause the main thread to wake up and
> process the WM_ENDSESSION message.  Right?

Yes, that would obviously be better.  But in any case, I don't think we 
want the input thread to sleep for 1000 seconds.  If we can't arrange an 
orderly shutdown, we should give up after a reasonable amount of time.

Ken