From: Alan Third <alan@idiocy.org>
To: Eli Zaretskii <eliz@gnu.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 18:45:32 +0000 [thread overview]
Message-ID: <20161230184532.GA3754@breton.holly.idiocy.org> (raw)
In-Reply-To: <83vau2u0a1.fsf@gnu.org>
On Thu, Dec 29, 2016 at 07:12:54PM +0200, Eli Zaretskii wrote:
> > Date: Wed, 28 Dec 2016 19:36:33 +0000
> > From: Alan Third <alan@idiocy.org>
> > Cc: charles@aurox.ch, 25265@debbugs.gnu.org
> >
> > I’m slowly beginning to understand what’s going on in ns_select. It
> > seems the idea is that it should detect both input on file descriptors
> > (using pselect in the background), and NS events coming from [NSApp
> > run].
>
> What do "NS events" include? Do they include, for example, keyboard
> input?
As far as I can tell it’s mouse and keyboard input, as well as
messages from the ‘window manager’, telling it to close the frame,
etc.
> > There is another thread that runs in a loop (fd_handler), and when
> > it’s signalled from ns_select, it runs pselect. At the same time
> > ns_select sets up a timer, then it calls [NSApp run].
>
> (I think ns_select only sets up a timer when there are no descriptors
> to watch, to avoid waking up the fd_handler thread in that case.)
>
> So this means there are 2 jobs to be done here: the pselect call and
> the [NSApp run] call.
Correct on both counts.
> > 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’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.
> 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?
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?)
Replace ns_select with pselect.
Thanks for helping with this, I don’t think I’d be able to work it out
on my own.
--
Alan Third
next prev parent reply other threads:[~2016-12-30 18:45 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 [this message]
2016-12-30 21:08 ` Eli Zaretskii
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20161230184532.GA3754@breton.holly.idiocy.org \
--to=alan@idiocy.org \
--cc=25265@debbugs.gnu.org \
--cc=charles@aurox.ch \
--cc=eliz@gnu.org \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.