From: Eli Zaretskii <eliz@gnu.org>
To: Alan Third <alan@idiocy.org>
Cc: charles@aurox.ch, 25265@debbugs.gnu.org
Subject: bug#25265: make-thread crashes in OS X 10.6
Date: Fri, 30 Dec 2016 23:08:54 +0200 [thread overview]
Message-ID: <83pok9ruop.fsf@gnu.org> (raw)
In-Reply-To: <20161230184532.GA3754@breton.holly.idiocy.org> (message from Alan Third on Fri, 30 Dec 2016 18:45:32 +0000)
> Date: Fri, 30 Dec 2016 18:45:32 +0000
> From: Alan Third <alan@idiocy.org>
> Cc: charles@aurox.ch, 25265@debbugs.gnu.org
>
> > > If there’s NS input, it’s processed by the NSApp loop
> >
> > Processed how? Shouldn't Emacs be involved in this processing? IOW,
> > these events should be read by Emacs, via the read_socket_hook.
>
> 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.
> 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?
> > One possible solution might be to let only one thread, say the main
> > thread, to call [NSApp run]. The other threads, when they get into
> > ns_select, will behave as if Emacs runs in non-GUI mode, and will only
> > call pselect. Not sure what this will mean from the POV of all
> > threads being equal (since the delicate dance between ns_select and
> > ns_read_socket is still unclear to me), but at least it might avoid
> > crashes and hangs. Can you try something like that?
>
> Yes, I will. Am I right in thinking that if we remove all the NSApp
> junk from ns_select it will literally just be calling pselect with
> the same arguments?
It looks like that, yes.
> 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?
> Thanks for helping with this, I don’t think I’d be able to work it out
> on my own.
Thank you for digging into the problem.
next prev parent reply other threads:[~2016-12-30 21:08 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-24 11:06 bug#25265: make-thread crashes in OS X 10.6 Charles A. Roelli
2016-12-24 17:51 ` Eli Zaretskii
2016-12-25 15:52 ` Eli Zaretskii
2016-12-26 13:09 ` Alan Third
2016-12-26 15:52 ` Eli Zaretskii
2016-12-26 20:56 ` Alan Third
2016-12-27 7:30 ` Eli Zaretskii
2016-12-27 10:44 ` Alan Third
2016-12-27 11:13 ` Eli Zaretskii
2016-12-28 19:36 ` Alan Third
2016-12-29 17:12 ` Eli Zaretskii
2016-12-30 18:45 ` Alan Third
2016-12-30 21:08 ` Eli Zaretskii [this message]
2016-12-30 22:05 ` Alan Third
2016-12-31 9:20 ` Eli Zaretskii
2016-12-31 16:09 ` bug#25265: [PATCH] Rework NS event handling (bug#25265) Alan Third
2016-12-31 16:25 ` Eli Zaretskii
2016-12-31 16:46 ` Alan Third
2017-01-01 15:03 ` Alan Third
2017-01-01 15:42 ` Eli Zaretskii
2017-03-06 20:02 ` bug#25265: make-thread crashes in OS X 10.6 Alan Third
2017-03-08 20:17 ` Charles A. Roelli
2017-03-14 14:49 ` Alan Third
2017-05-02 20:49 ` Alan Third
2017-06-12 19:32 ` Charles A. Roelli
2017-06-13 20:46 ` Alan Third
2017-06-15 18:57 ` Charles A. Roelli
2017-06-15 19:04 ` Alan Third
2017-06-15 19:14 ` Noam Postavsky
2017-06-16 19:45 ` Alan Third
2017-06-16 20:05 ` Noam Postavsky
2017-06-16 20:51 ` Alan Third
2017-06-18 13:05 ` Charles A. Roelli
2017-06-18 14:01 ` Alan Third
2017-06-19 18:34 ` Charles A. Roelli
2017-07-01 12:04 ` Alan Third
2017-07-04 6:59 ` Charles A. Roelli
2017-07-04 12:04 ` npostavs
[not found] ` <20170705193642.GA18888@breton.holly.idiocy.org>
2017-07-06 9:25 ` Charles A. Roelli
2017-07-06 17:10 ` Charles A. Roelli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83pok9ruop.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=25265@debbugs.gnu.org \
--cc=alan@idiocy.org \
--cc=charles@aurox.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).