GNU bug report logs - #38748
28.0.50; crash on MacOS 10.15.2

Previous Next

Full log

Message #161 received at 38748 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Pip Cet <pipcet <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, andreyk.mad <at> gmail.com, rpluim <at> gmail.com,
 jguenther <at> gmail.com, 38748 <at> debbugs.gnu.org
Subject: Re: bug#38748: 28.0.50; crash on MacOS 10.15.2
Date: Sat, 11 Jan 2020 19:07:15 +0000

On Sat, Jan 11, 2020 at 02:13:43PM +0000, Pip Cet wrote:
> On Sat, Jan 11, 2020 at 1:59 PM Alan Third <alan <at> idiocy.org> wrote:
> > > It's my impression that macOS forces us to run in several threads,
> > > even though we don't really want to do so. For example, changeFont in
> > > nsterm.m appears not to assume it's run on the main thread, but calls
> > > build_string, which sounds dangerous to me.
> >
> > What makes you think it’s assuming it may not be run on the main
> > thread?
> 
> The way it doesn't simply call Lisp, but sets up an event to be
> handled in the event loop. How is changeFont actually called? Would it
> be safe to call Lisp from it?

changeFont is called during the NS run (event) loop which I don’t
think is safe for calling lisp.

Effectively Emacs requests the font panel to be opened and then any
changes made in it are handled as though they’re user input events. I
remember looking into it because it doesn’t work like on other
toolkits, but because it’s this detached thing that only communicates
through input events while Emacs continues running it makes it
difficult to match its behaviour.

-- 
Alan Third

Previous Next

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