GNU bug report logs - #25265
make-thread crashes in OS X 10.6

Previous Next

Full log

View this message in rfc822 format

From: Alan Third <alan <at> idiocy.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: charles <at> aurox.ch, 25265 <at> debbugs.gnu.org
Subject: bug#25265: make-thread crashes in OS X 10.6
Date: Fri, 30 Dec 2016 22:05:44 +0000

On Fri, Dec 30, 2016 at 11:08:54PM +0200, Eli Zaretskii wrote:
> > Date: Fri, 30 Dec 2016 18:45:32 +0000
> > From: Alan Third <alan <at> idiocy.org>
> > Cc: charles <at> aurox.ch, 25265 <at> debbugs.gnu.org
> > 
> > Ah! Is this the missing piece of the puzzle? When the [NSApp run] loop
> > receives an event, say keyboard input, it creates an emacs_event and
> > then raises SIGIO (via hold_event). SIGIO causes ns_read_socket to be
> > run, which ALSO tries to run [NSApp run].
> > 
> > Am I right in thinking that raising SIGIO will cause ns_read_socket to
> > be potentially run immediately? Asynchronously?
> 
> I very much hope not.  We don't run any non-trivial code from a signal
> handler.  I'd expect SIGIO just to set a flag, and then the resulting
> input be processed when we call unblock_input next time, and the
> blocking level gets to zero.  Then we run process_pending_signals,
> which calls handle_async_input, and that's where ns_read_socket will
> be called by gobble_input.

OK. I am, again, none the wiser.

> > I’ve just commented out the section of ns_read_socket that calls
> > [NSApp run] and I can’t see any difference in behaviour. I suspect
> > that someone’s doubled up on it when they didn’t need to.
> 
> I cannot help you here.  Maybe it's needed for Emacs to be more
> responsive?  If you run "git log -L" on ns_read_socket, does the
> history tell anything about why this call was added?  Perhaps some
> discussion or bug report?

It’s been there since the NS port was integrated, it seems.

> > So, my plan of action:
> > 
> > Run [NSApp run] in it’s own thread with no flow control (unless it’s
> > important that emacs events are only created at specific times?)
> 
> How will that thread communicate the events to Emacs?

I’m hoping using the same method as it does now. It creates emacs
events from the NS events, and then fires SIGIO.

I have run into a problem almost right away, though. I don’t know how
to go about creating this thread.

The NSApp loop needs to run in the ‘main’ thread on macOS. I
understand the main thread is always the original thread, so if I want
to use it for the NSApp loop, I need to move Emacs’ normal operation
into a child thread.

I don’t have any experience with pthreads and can’t see any obvious
way of doing it (and I think, from my experiments, it breaks unexec or
something). Is it possible, or can you think of a better way of
handling this?

Thanks!
-- 
Alan Third

Previous Next

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