GNU bug report logs - #60810
30.0.50; `while-no-input' in GUI(macOS) is much slower than emacs -nw

Previous Next

Full log

View this message in rfc822 format

From: Allen Wang <allenhw1996 <at> gmail.com>
To: Po Lu <luangruo <at> yahoo.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 60810 <at> debbugs.gnu.org
Subject: bug#60810: 30.0.50; `while-no-input' in GUI(macOS) is much slower than emacs -nw
Date: Sun, 15 Jan 2023 12:48:59 -0800

[Message part 1 (text/plain, inline)]

Thank you for the quick response and the info. Sounds like this can't be
fixed easily; I'll see if polling-period works for me.

On Sun, Jan 15, 2023 at 1:41 AM Po Lu <luangruo <at> yahoo.com> wrote:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > Does NS use a separate thread to handle input events?
>
> Unfortunately not.
>
> > If so, could that separate thread set quit-flag when we are under
> > throw-on-input, if it detects a suitable input event?  The w32 port
> > does that, see signal_user_input in w32fns.c.  This should allow the
> > Lisp thread detect that input is pending in a more timely fashion.
>
> I understand that approach, it's taken in the Android port as well.
> Unfortunately, it cannot work because the NS port currently runs in the
> same thread that Lisp runs in.
>
> Thanks.
>

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.