bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Ken Brown
Subject: bug#25875: 26.0.50; Hang logging out of MS-Windows
Date: Sun, 26 Feb 2017 13:58:23 -0500
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1

On 2/26/2017 1:25 PM, Eli Zaretskii wrote:
Cc: address@hidden
From: Ken Brown <address@hidden>
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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]