UI input unresponsive on macOS

UI input unresponsive on macOS

[Bob Halley]

I was running from the master branch with a build containing the recent macOS event changes, e0e5b0f4a4ce1d19ee0240c514dedd873d4165dc, and the UI became unresponsive to the mouse and keyboard.  I had to kill Emacs by hand.

I was in the middle of something so I rolled back to my prior Emacs build.  I also am not sure how to debug this.  If someone tells me how to gather info that’s useful should this happen again, I’m willing to reinstate the build and report if it fails.

/Bob

Re: UI input unresponsive on macOS

[Alan Third]

[-- Attachment #1: Type: text/plain, Size: 1022 bytes --]

On Tue, Jan 03, 2017 at 05:36:01AM -0800, Bob Halley wrote:
> I was running from the master branch with a build containing the
> recent macOS event changes,
> e0e5b0f4a4ce1d19ee0240c514dedd873d4165dc, and the UI became
> unresponsive to the mouse and keyboard. I had to kill Emacs by hand.
> 
> I was in the middle of something so I rolled back to my prior Emacs
> build. I also am not sure how to debug this. If someone tells me how
> to gather info that’s useful should this happen again, I’m willing
> to reinstate the build and report if it fails.

Hi Bob, I’m working on coming up with a better solution.

Can you try the attached patch? So far the only problem I’ve seen is
that emacsclient doesn’t return to the shell when it exits. I suspect
it’s because I’m not monitoring write or exeption fds correctly.

If you spot any other problems, either reply here or to bug 25265.

Additionally, if anyone has any better ideas of how to deal with
ns_select, please feel free to let me know.
-- 
Alan Third

[-- Attachment #2: 0001-Improve-NS-event-handling-bug-25265.patch --]
[-- Type: text/plain, Size: 4546 bytes --]

From 9663d300d231242fc77f93a35219d56ba9c90601 Mon Sep 17 00:00:00 2001
From: Alan Third <alan@idiocy.org>
Date: Tue, 3 Jan 2017 14:16:37 +0000
Subject: [PATCH] Improve NS event handling (bug#25265)

* src/nsterm.h: Remove reference to timeout_handler.
* src/nsterm.m (ns_select): Monitor fd changes using NSFileHandler.
---
 src/nsterm.h |  1 -
 src/nsterm.m | 62 +++++++++++++++++++++++++++++++++++++++++++-----------------
 2 files changed, 45 insertions(+), 18 deletions(-)

diff --git a/src/nsterm.h b/src/nsterm.h
index dc222a7..8b5b691 100644
--- a/src/nsterm.h
+++ b/src/nsterm.h
@@ -392,7 +392,6 @@ char const * nstrace_fullscreen_type_name (int);
 - (void)sendEvent: (NSEvent *)theEvent;
 - (void)showPreferencesWindow: (id)sender;
 - (BOOL) openFile: (NSString *)fileName;
-- (void)timeout_handler: (NSTimer *)timedEntry;
 - (BOOL)fulfillService: (NSString *)name withArg: (NSString *)arg;
 #ifdef NS_IMPL_GNUSTEP
 - (void)sendFromMainThread:(id)unused;
diff --git a/src/nsterm.m b/src/nsterm.m
index 98fd8ab..51cccd0 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -4098,28 +4098,55 @@ overwriting cursor (usually when cursor on a tab) */
     return pselect(nfds, readfds, writefds,
                    exceptfds, timeout, sigmask);
 
-  result = pselect(nfds, readfds, writefds, exceptfds,
-                   &(struct timespec){.tv_sec = 0, .tv_nsec = 100},
-                   sigmask);
-
   [outerpool release];
   outerpool = [[NSAutoreleasePool alloc] init];
 
+  /* Set up one NSFileHandle for each fd we want to monitor. */
+  for (int i = 0 ; i < nfds ; i++)
+    {
+      if ((readfds != NULL && FD_ISSET(i, readfds))
+          || (writefds != NULL && FD_ISSET(i, writefds))
+          || (exceptfds != NULL &&FD_ISSET(i, exceptfds)))
+        {
+          NSFileHandle *fh = [[NSFileHandle alloc] initWithFileDescriptor: i
+                                                           closeOnDealloc: NO];
+          /* Send a notification to EmacsApp:fileHandleDataAvailable,
+             which will raise an appDefined event. */
+          /* NOTE: I don't think this will pick up writes and
+             exceptions, so ns_select may not always behave correctly.
+             I've yet to see a problem, though. */
+          [fh waitForDataInBackgroundAndNotify];
+          [fh autorelease];
+        }
+    }
+
   if (timeout)
     {
       double time = timespectod (*timeout);
-      timeout_date = [NSDate dateWithTimeIntervalSinceNow:time];
+      timeout_date = [NSDate dateWithTimeIntervalSinceNow: time];
     }
 
   /* Listen for a new NSEvent. */
-  ns_event = [NSApp nextEventMatchingMask:NSEventMaskAny
-                                untilDate:timeout_date
-                                   inMode:NSDefaultRunLoopMode
-                                  dequeue:NO];
+  ns_event = [NSApp nextEventMatchingMask: NSEventMaskAny
+                                untilDate: timeout_date
+                                   inMode: NSDefaultRunLoopMode
+                                  dequeue: NO];
 
   if (ns_event != nil)
     {
-      raise (SIGIO);
+      if ([ns_event type] == NSEventTypeApplicationDefined
+          && [ns_event data1] == -3)
+        {
+          result = pselect(nfds, readfds, writefds, exceptfds,
+                           &(struct timespec){.tv_sec = 0, .tv_nsec = 0},
+                           sigmask);
+        }
+      else
+        {
+          raise (SIGIO);
+          errno = EINTR;
+          return -1;
+        }
     }
 
   return result;
@@ -5132,6 +5159,12 @@ - (void)applicationDidFinishLaunching: (NSNotification *)notification
 	 object:nil];
 #endif
 
+  [[NSNotificationCenter defaultCenter]
+      addObserver: self
+         selector: @selector (fileHandleDataAvailable:)
+             name: NSFileHandleDataAvailableNotification
+           object: nil];
+
   ns_send_appdefined (-2);
 }
 
@@ -5315,14 +5348,9 @@ - (void)applicationDidResignActive: (NSNotification *)notification
 
    ========================================================================== */
 
-
-- (void)timeout_handler: (NSTimer *)timedEntry
-/* --------------------------------------------------------------------------
-     The timeout specified to ns_select has passed.
-   -------------------------------------------------------------------------- */
+- (void)fileHandleDataAvailable: (NSNotification *)notification
 {
-  /*NSTRACE ("timeout_handler"); */
-  ns_send_appdefined (-2);
+  ns_send_appdefined (-3);
 }
 
 - (void)sendFromMainThread:(id)unused
-- 
2.10.2

Re: UI input unresponsive on macOS

[Bob Halley]

> Can you try the attached patch? 

Will do, thanks!

/Bob

Re: UI input unresponsive on macOS

[Bob Halley]

[-- Attachment #1: Type: text/plain, Size: 4689 bytes --]


> Can you try the attached patch?

It didn’t fix things, but I did find a way to reproduce the problem at will.

If start emacs, and then you run

    open -a /Applications/Emacs.app whatever_file_here

For a file which isn’t open, then the UI becomes unresponsive to input.  Typing C-G seems to unstick it eventually, but there can be very long delays (I timed one at 49 seconds) before it beeps and the UI becomes responsive.  I’ve seen it spontaneously complete too, again after a long time (at least 30 seconds), but usually it does not complete.

If I look at it with lldb, all of the threads are blocked, and thread 1 looks like:

(lldb) bt
* thread #1: tid = 0x4ad0a2, 0x00007fff9f7ebaff CoreFoundation`__CFRunLoopCollectSources0 + 31, stop reason = signal SIGSTOP
  * frame #0: 0x00007fff9f7ebaff CoreFoundation`__CFRunLoopCollectSources0 + 31
    frame #1: 0x00007fff9f7b91f2 CoreFoundation`__CFSetApplyFunction_block_invoke + 18
    frame #2: 0x00007fff9f7a54ba CoreFoundation`CFBasicHashApply + 122
    frame #3: 0x00007fff9f7b9199 CoreFoundation`CFSetApplyFunction + 185
    frame #4: 0x00007fff9f7eb8be CoreFoundation`__CFRunLoopDoSources0 + 110
    frame #5: 0x00007fff9f7eaf76 CoreFoundation`__CFRunLoopRun + 934
    frame #6: 0x00007fff9f7ea974 CoreFoundation`CFRunLoopRunSpecific + 420
    frame #7: 0x00007fff9ed76acc HIToolbox`RunCurrentEventLoopInMode + 240
    frame #8: 0x00007fff9ed76809 HIToolbox`ReceiveNextEventCommon + 184
    frame #9: 0x00007fff9ed76736 HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 71
    frame #10: 0x00007fff9d31cae4 AppKit`_DPSNextEvent + 1120
    frame #11: 0x00007fff9da9721f AppKit`-[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 2789
    frame #12: 0x00000001001b3866 Emacs`ns_select(nfds=4, readfds=0x00007fff5fbfee00, writefds=0x00007fff5fbfed80, exceptfds=0x0000000000000000, timeout=<unavailable>, sigmask=<unavailable>) + 678 at nsterm.m:4130 [opt]
    frame #13: 0x00000001001a04a8 Emacs`really_call_select(arg=0x00007fff5fbfeba0) + 88 at thread.c:520 [opt]
    frame #14: 0x000000010011ec7c Emacs`flush_stack_call_func(func=<unavailable>, arg=<unavailable>) + 44 at alloc.c:5137 [opt]
    frame #15: 0x00000001001a0447 Emacs`thread_select(func=<unavailable>, max_fds=<unavailable>, rfds=<unavailable>, wfds=<unavailable>, efds=<unavailable>, timeout=<unavailable>, sigmask=0x0000000000000000) + 55 at thread.c:543 [opt]
    frame #16: 0x000000010018400e Emacs`wait_reading_process_output(time_limit=<unavailable>, nsecs=<unavailable>, read_kbd=<unavailable>, do_display=<unavailable>, wait_for_cell=0, wait_proc=<unavailable>, just_wait_proc=<unavailable>) + 4142 at process.c:5350 [opt]
    frame #17: 0x0000000100008005 Emacs`sit_for(timeout=<unavailable>, reading=<unavailable>, display_option=1) + 261 at dispnew.c:5763 [opt]
    frame #18: 0x00000001000c3ab7 Emacs`read_char(commandflag=1, map=4431829235, prev_event=0, used_mouse_menu=0x00007fff5fbff7df, end_time=0x0000000000000000) + 5511 at keyboard.c:2725 [opt]
    frame #19: 0x00000001000c062f Emacs`read_key_sequence(keybuf=<unavailable>, bufsize=30, prompt=<unavailable>, dont_downcase_last=<unavailable>, can_return_switch_frame=<unavailable>, fix_current_buffer=<unavailable>, prevent_redisplay=<unavailable>) + 1839 at keyboard.c:9139 [opt]
    frame #20: 0x00000001000bed32 Emacs`command_loop_1 + 1202 at keyboard.c:1373 [opt]
    frame #21: 0x000000010013d347 Emacs`internal_condition_case(bfun=(Emacs`command_loop_1 at keyboard.c:1264), handlers=<unavailable>, hfun=(Emacs`cmd_error at keyboard.c:943)) + 87 at eval.c:1326 [opt]
    frame #22: 0x00000001000cde20 Emacs`command_loop_2(ignore=<unavailable>) + 48 at keyboard.c:1115 [opt]
    frame #23: 0x000000010013cbfe Emacs`internal_catch(tag=<unavailable>, func=(Emacs`command_loop_2 at keyboard.c:1111), arg=0) + 78 at eval.c:1092 [opt]
    frame #24: 0x00000001000bdf7e Emacs`command_loop + 158 at keyboard.c:1094 [opt]
    frame #25: 0x00000001000bde8f Emacs`recursive_edit_1 + 111 at keyboard.c:700 [opt]
    frame #26: 0x00000001000be0c3 Emacs`Frecursive_edit + 227 at keyboard.c:771 [opt]
    frame #27: 0x00000001000bcc9d Emacs`main(argc=0, argv=<unavailable>) + 6157 at emacs.c:1684 [opt]
    frame #28: 0x00007fffb4d43255 libdyld.dylib`start + 1

The other threads didn’t look interesting, but I could be wrong :)

Sometimes when I “continue” in the debugger it unsticks whatever is stuck, though the file I was trying to open never opens.

> So far the only problem I’ve seen is
> that emacsclient doesn’t return to the shell when it exits.

Yeah, I see that too.

/Bob



[-- Attachment #2: Type: text/html, Size: 13827 bytes --]

Re: UI input unresponsive on macOS

[Alan Third]

On Tue, Jan 03, 2017 at 08:59:43AM -0800, Bob Halley wrote:
> 
> > Can you try the attached patch?
> 
> It didn’t fix things, but I did find a way to reproduce the problem at will.
> 
> If start emacs, and then you run
> 
>     open -a /Applications/Emacs.app whatever_file_here

I didn’t even know you could do that. I wonder if I’ve accidentally
clobbered some notification or event somewhere. I’ll have to try and
work out how this works.

> For a file which isn’t open, then the UI becomes unresponsive to
> input. Typing C-G seems to unstick it eventually, but there can be
> very long delays (I timed one at 49 seconds) before it beeps and the
> UI becomes responsive. I’ve seen it spontaneously complete too,
> again after a long time (at least 30 seconds), but usually it does
> not complete.

I had some trouble with that sort of thing before. What was happening
then was that a time‐out in ns_select was being reached before it
would react. I had thought I’d fixed that particular problem for most
cases in the last patch, though.

> Sometimes when I “continue” in the debugger it unsticks whatever is
> stuck, though the file I was trying to open never opens.

One of the bugs I had with an earlier version of this code would go
away when I put a breakpoint on the relevant function. Debugging can
be hard. :)

Thanks for your help.

-- 
Alan Third

Re: UI input unresponsive on macOS

[Gong-Yi Liao 廖宮毅]

I have similar issue on Linux/Gtk3. I am wondering if this is a
threading/concurrency issue.

On Tue, Jan 3, 2017 at 11:49 AM, Alan Third <alan@idiocy.org> wrote:
> On Tue, Jan 03, 2017 at 08:59:43AM -0800, Bob Halley wrote:
>>
>> > Can you try the attached patch?
>>
>> It didn’t fix things, but I did find a way to reproduce the problem at will.
>>
>> If start emacs, and then you run
>>
>>     open -a /Applications/Emacs.app whatever_file_here
>
> I didn’t even know you could do that. I wonder if I’ve accidentally
> clobbered some notification or event somewhere. I’ll have to try and
> work out how this works.
>
>> For a file which isn’t open, then the UI becomes unresponsive to
>> input. Typing C-G seems to unstick it eventually, but there can be
>> very long delays (I timed one at 49 seconds) before it beeps and the
>> UI becomes responsive. I’ve seen it spontaneously complete too,
>> again after a long time (at least 30 seconds), but usually it does
>> not complete.
>
> I had some trouble with that sort of thing before. What was happening
> then was that a time‐out in ns_select was being reached before it
> would react. I had thought I’d fixed that particular problem for most
> cases in the last patch, though.
>
>> Sometimes when I “continue” in the debugger it unsticks whatever is
>> stuck, though the file I was trying to open never opens.
>
> One of the bugs I had with an earlier version of this code would go
> away when I put a breakpoint on the relevant function. Debugging can
> be hard. :)
>
> Thanks for your help.
>
> --
> Alan Third
>

Re: UI input unresponsive on macOS

[Eli Zaretskii]

> From: Gong-Yi Liao 廖宮毅 <gongyi.liao@gmail.com>
> Date: Tue, 3 Jan 2017 21:52:56 -0600
> Cc: Bob Halley <halley@play-bow.org>, emacs-devel@gnu.org
> 
> I have similar issue on Linux/Gtk3. I am wondering if this is a
> threading/concurrency issue.

Unlikely, at least not in the same way as the Darwin users are
experiencing.

Please describe your problems in a separate thread and in more detail,
preferably via "M-x report-emacs-bug RET".

Thanks.

Re: UI input unresponsive on macOS

[Gong-Yi Liao 廖宮毅]

[-- Attachment #1: Type: text/plain, Size: 764 bytes --]

When I M-X gnus, Emacs runs (with or without -Q at command line)
normally; but when I use

(make-thread #'gnus "gnus")

Emacs just hangs by the dialog whose screenshot is attached as a png file.



On Wed, Jan 4, 2017 at 9:38 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Gong-Yi Liao 廖宮毅 <gongyi.liao@gmail.com>
>> Date: Tue, 3 Jan 2017 21:52:56 -0600
>> Cc: Bob Halley <halley@play-bow.org>, emacs-devel@gnu.org
>>
>> I have similar issue on Linux/Gtk3. I am wondering if this is a
>> threading/concurrency issue.
>
> Unlikely, at least not in the same way as the Darwin users are
> experiencing.
>
> Please describe your problems in a separate thread and in more detail,
> preferably via "M-x report-emacs-bug RET".
>
> Thanks.

[-- Attachment #2: Screenshot from 2017-01-04 22-33-36.png --]
[-- Type: image/png, Size: 229383 bytes --]

Re: UI input unresponsive on macOS

[Eli Zaretskii]

> From: Gong-Yi Liao 廖宮毅 <gongyi.liao@gmail.com>
> Date: Wed, 4 Jan 2017 22:34:58 -0600
> Cc: Alan Third <alan@idiocy.org>, Bob Halley <halley@play-bow.org>, emacs-devel@gnu.org
> 
> When I M-X gnus, Emacs runs (with or without -Q at command line)
> normally; but when I use
> 
> (make-thread #'gnus "gnus")
> 
> Emacs just hangs by the dialog whose screenshot is attached as a png file.

The image seems to indicate that Emacs is waiting for you to answer
the question.  Did you try to click "Yes" or "No" on the dialog Emacs
pops up?

Re: UI input unresponsive on macOS

[Gong-Yi Liao 廖宮毅]

[-- Attachment #1: Type: text/plain, Size: 736 bytes --]

I did clicked both buttons but none of them responsive and the UI hanged.



On Thu, Jan 5, 2017, 09:38 Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Gong-Yi Liao 廖宮毅 <gongyi.liao@gmail.com>
> > Date: Wed, 4 Jan 2017 22:34:58 -0600
> > Cc: Alan Third <alan@idiocy.org>, Bob Halley <halley@play-bow.org>,
> emacs-devel@gnu.org
> >
> > When I M-X gnus, Emacs runs (with or without -Q at command line)
> > normally; but when I use
> >
> > (make-thread #'gnus "gnus")
> >
> > Emacs just hangs by the dialog whose screenshot is attached as a png
> file.
>
> The image seems to indicate that Emacs is waiting for you to answer
> the question.  Did you try to click "Yes" or "No" on the dialog Emacs
> pops up?
>

[-- Attachment #2: Type: text/html, Size: 1624 bytes --]

Re: UI input unresponsive on macOS

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 05 Jan 2017 17:00:53 +0000, Gong-Yi Liao 廖宮毅 <gongyi.liao@gmail.com> said:

>> > When I M-X gnus, Emacs runs (with or without -Q at command line)
>> > normally; but when I use
>> >
>> > (make-thread #'gnus "gnus")
>> >
>> > Emacs just hangs by the dialog whose screenshot is attached as a png
>> file.
>> 
>> The image seems to indicate that Emacs is waiting for you to answer
>> the question.  Did you try to click "Yes" or "No" on the dialog Emacs
>> pops up?
>> 
> I did clicked both buttons but none of them responsive and the UI hanged.

The following recipe seems to behave differently depending on the
toolkit.

(make-thread
 (lambda ()
   (let (last-nonmenu-event)
     (setq test (y-or-n-p-with-timeout "test" 2 'timeout)))))

Athena: Works.
GTK+2: Timeout works, but buttons are not displayed.
GTK+3: Hangs.
NS: Crashes.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: UI input unresponsive on macOS

[Alan Third]

On Thu, Oct 05, 2017 at 12:40:54PM +0900, YAMAMOTO Mitsuharu wrote:
> >>>>> On Thu, 05 Jan 2017 17:00:53 +0000, Gong-Yi Liao 廖宮毅 <gongyi.liao@gmail.com> said:
> 
> The following recipe seems to behave differently depending on the
> toolkit.
> 
> (make-thread
>  (lambda ()
>    (let (last-nonmenu-event)
>      (setq test (y-or-n-p-with-timeout "test" 2 'timeout)))))
> 
> Athena: Works.
> GTK+2: Timeout works, but buttons are not displayed.
> GTK+3: Hangs.
> NS: Crashes.

I’m not sure how we could handle that on NS. Perhaps just refuse to
display the dialogue at all, and return nil?
-- 
Alan Third

Re: UI input unresponsive on macOS

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 16 Nov 2017 19:33:43 +0000, Alan Third <alan@idiocy.org> said:

>> The following recipe seems to behave differently depending on the
>> toolkit.
>> 
>> (make-thread
>> (lambda ()
>> (let (last-nonmenu-event)
>> (setq test (y-or-n-p-with-timeout "test" 2 'timeout)))))
>> 
>> Athena: Works.
>> GTK+2: Timeout works, but buttons are not displayed.
>> GTK+3: Hangs.
>> NS: Crashes.

> I’m not sure how we could handle that on NS. Perhaps just refuse to
> display the dialogue at all, and return nil?

With Xcode 9, you can catch several problematic cases on NS such as
(make-thread 'make-frame) using the Main Thread Checker mentioned in
http://lists.gnu.org/archive/html/emacs-devel/2017-10/msg00418.html .

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: UI input unresponsive on macOS

[Eli Zaretskii]

> Date: Thu, 16 Nov 2017 19:33:43 +0000
> From: Alan Third <alan@idiocy.org>
> Cc: Gong-Yi Liao 廖宮毅 <gongyi.liao@gmail.com>,
> 	Eli Zaretskii <eliz@gnu.org>, halley@play-bow.org,
> 	emacs-devel@gnu.org
> 
> > (make-thread
> >  (lambda ()
> >    (let (last-nonmenu-event)
> >      (setq test (y-or-n-p-with-timeout "test" 2 'timeout)))))
> > 
> > Athena: Works.
> > GTK+2: Timeout works, but buttons are not displayed.
> > GTK+3: Hangs.
> > NS: Crashes.
> 
> I’m not sure how we could handle that on NS. Perhaps just refuse to
> display the dialogue at all, and return nil?

If you can detect this situation, it's possible.  But silently
returning nil might not be a good idea, as it's hard to distinguish
that from normal return.  How about displaying a warning?  (You cannot
easily error out in a thread, so that's not a good option.)

Re: UI input unresponsive on macOS

[Alan Third]

On Fri, Nov 17, 2017 at 03:53:56PM +0200, Eli Zaretskii wrote:
> > Date: Thu, 16 Nov 2017 19:33:43 +0000
> > From: Alan Third <alan@idiocy.org>
> > Cc: Gong-Yi Liao 廖宮毅 <gongyi.liao@gmail.com>,
> > 	Eli Zaretskii <eliz@gnu.org>, halley@play-bow.org,
> > 	emacs-devel@gnu.org
> > 
> > > (make-thread
> > >  (lambda ()
> > >    (let (last-nonmenu-event)
> > >      (setq test (y-or-n-p-with-timeout "test" 2 'timeout)))))
> > > 
> > > Athena: Works.
> > > GTK+2: Timeout works, but buttons are not displayed.
> > > GTK+3: Hangs.
> > > NS: Crashes.
> > 
> > I’m not sure how we could handle that on NS. Perhaps just refuse to
> > display the dialogue at all, and return nil?
> 
> If you can detect this situation, it's possible.  But silently
> returning nil might not be a good idea, as it's hard to distinguish
> that from normal return.  How about displaying a warning?  (You cannot
> easily error out in a thread, so that's not a good option.)

NS GUI elements need to be handled in the main thread and it’s easy
enough to check whether we’re in the main thread before trying to
display the dialogue box. It’s also possible we could pass the request
for the dialogue box over to the main thread, but I don’t know how to
deal with return values and so on.

Displaying a warning seems like the best option. Thanks.
-- 
Alan Third

Re: UI input unresponsive on macOS

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 17 Nov 2017 17:42:26 +0000, Alan Third <alan@idiocy.org> said:

>> > I’m not sure how we could handle that on NS. Perhaps just refuse
>> > to display the dialogue at all, and return nil?
>> 
>> If you can detect this situation, it's possible.  But silently
>> returning nil might not be a good idea, as it's hard to distinguish
>> that from normal return.  How about displaying a warning?  (You
>> cannot easily error out in a thread, so that's not a good option.)

> NS GUI elements need to be handled in the main thread and it’s easy
> enough to check whether we’re in the main thread before trying to
> display the dialogue box.

Not just for creating a dialog box, but also for an ordinary Emacs
frame (it does not always crash, but it sometimes does).  As I said,
the Main Thread Checker makes it easier to detect these cases.

The Main Thread Checker reports even if you try to move/resize an
existing NSWindow in a non-main thread.  Actually even -[NSView frame]
seems to be black-listed.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: UI input unresponsive on macOS

[Alan Third]

On Sat, Nov 18, 2017 at 09:24:17AM +0900, YAMAMOTO Mitsuharu wrote:
> 
> > NS GUI elements need to be handled in the main thread and it’s easy
> > enough to check whether we’re in the main thread before trying to
> > display the dialogue box.
> 
> Not just for creating a dialog box, but also for an ordinary Emacs
> frame (it does not always crash, but it sometimes does).  As I said,
> the Main Thread Checker makes it easier to detect these cases.
> 
> The Main Thread Checker reports even if you try to move/resize an
> existing NSWindow in a non-main thread.  Actually even -[NSView frame]
> seems to be black-listed.

Yes, this looks like it could be a very large job as lots of functions
will need a main thread guard. Even something as innocent looking as
setting a frame parameter causes an error.

I put a guard in the dialog box code and tried the original code again

    (make-thread #'gnus "gnus")

and it threw up a warning in redisplay, so I suppose we’ll have to
prevent redisplay happening in a sub‐thread.

    2017-12-02 16:36:15.551 Emacs[6922:22033201] Warning: Illegal attempt to access GUI elements from sub-thread.
    CoreAnimation: warning, deleted thread with uncommitted CATransaction; created by:
    <snip backtrace>
-- 
Alan Third

Re: UI input unresponsive on macOS

[Alan Third]

On Tue, Jan 03, 2017 at 02:36:21PM +0000, Alan Third wrote:
> On Tue, Jan 03, 2017 at 05:36:01AM -0800, Bob Halley wrote:
> > I was running from the master branch with a build containing the
> > recent macOS event changes,
> > e0e5b0f4a4ce1d19ee0240c514dedd873d4165dc, and the UI became
> > unresponsive to the mouse and keyboard. I had to kill Emacs by hand.
> > 
> > I was in the middle of something so I rolled back to my prior Emacs
> > build. I also am not sure how to debug this. If someone tells me how
> > to gather info that’s useful should this happen again, I’m willing
> > to reinstate the build and report if it fails.
> 
> Hi Bob, I’m working on coming up with a better solution.

I’ve reverted this change for now.
-- 
Alan Third