GNU bug report logs -
#25875
26.0.50; Hang logging out of MS-Windows
Previous Next
Reported by: Richard Copley <rcopley <at> gmail.com>
Date: Sat, 25 Feb 2017 19:37:01 UTC
Severity: normal
Found in version 26.0.50
Done: Ken Brown <kbrown <at> cornell.edu>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
On 2/26/2017 1:25 PM, Eli Zaretskii wrote:
>> Cc: 25875 <at> debbugs.gnu.org
>> From: Ken Brown <kbrown <at> 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
This bug report was last modified 8 years and 85 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.