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: Thu, 29 Dec 2016 19:12:54 +0200 [thread overview]
Message-ID: <83vau2u0a1.fsf@gnu.org> (raw)
In-Reply-To: <20161228193633.GA47290@breton.holly.idiocy.org> (message from Alan Third on Wed, 28 Dec 2016 19:36:33 +0000)
> Date: Wed, 28 Dec 2016 19:36:33 +0000
> From: Alan Third <alan@idiocy.org>
> Cc: charles@aurox.ch, 25265@debbugs.gnu.org
>
> > That's probably the only reasonable way. But why does it use
> > record_unwind_protect and unbind_to in the first place? What happens
> > if the user presses C-g while the event loop runs?
>
> It was added in change 08f27aa39c498d34418c7420b33bf2db913827c3 which
> relates to bug 18345. Previously it was simply apploopnr--, but
> sometimes users would find themselves in a situation where that line
> was never run (hitting C‐g while the event loop runs?) so the next
> time ns_select (or ns_read_socket) ran it aborted. I take it unbind_to
> fixes that particular problem.
>
> Is there a safer way of ensuring that apploopnr is decremented?
There could be, but I see that ns_select and ns_read_socket use it for
some kind of synchronization between them, which I don't really
understand, so I cannot answer that question.
> 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?
Also, does C-g cause a signal or some other async event on NS, which
could potentially interrupt the [NSApp run] stuff? Or could SIGIO do
that (does NS use SIGIO for input?)?
If nothing could interrupt/QUIT [NSApp run], then I don't really
understand why we have unwind_protect there. The bug in question
cites some undisclosed Lisp for reproducing the problem, so I wonder
how could that cause [NSApp run] to be interrupted and longjmp to
higher level.
> 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.
> If either the pselect thread, or the timer run out before any input is
> detected, they send a user defined event to the NSApp event loop so it
> ends.
>
> Similarly if the pselect thread detects input it sends an event to the
> NSApp loop, which then ends.
>
> 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.
> Whatever happens, the NSApp loop eventually returns control back to
> ns_select, which works out what happened by examining the last NS
> event and returns the relevant value.
>
> I have my doubts this is thread safe.
It isn't. Unless each Emacs application thread will have its own
fd_handler thread.
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?
> The communication between ns_select and fd_handler is done by
> setting static variables and then running:
>
> c = 'g';
> emacs_write_sig (selfds[1], &c, 1);
>
> I don’t really know what that does. Sends something on an fd?
Yes. I guess 'g' stands for GO and 's' stands for SUSPEND. These are
commands to the fd_handler thread, or so it seems.
Thanks.
next prev parent reply other threads:[~2016-12-29 17:12 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 [this message]
2016-12-30 18:45 ` Alan Third
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=83vau2u0a1.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 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.