[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#25265: make-thread crashes in OS X 10.6
From: |
Eli Zaretskii |
Subject: |
bug#25265: make-thread crashes in OS X 10.6 |
Date: |
Tue, 27 Dec 2016 13:13:11 +0200 |
> Date: Tue, 27 Dec 2016 10:44:24 +0000
> From: Alan Third <alan@idiocy.org>
> Cc: charles@aurox.ch, 25265@debbugs.gnu.org
>
> OK, I’ve ended up just using printf and it looks like in this thread
> current_thread is null.
This happens in only one place: run_thread, after a thread exits. And
yes, it's a bad idea to rely on current_thread being non-NULL in code
that is run when other threads could be running.
More generally, this means calling unbind_to, i.e. unwinding the Lisp
stack, is not going to work in this context at all, because that in
effect runs Lisp when more than one thread could run their code.
> > > > [NSApp run];
> > > >
> > > > Can this part and its surrounding code be made thread-safe?
> > >
> > > I think this particular method call has to be done *only* from the
> > > main thread. I imagine that could be a problem.
> >
> > It could be a problem, yes. But what does this do, exactly, and why
> > does it need to be called as part of ns_select?
>
> It runs an event loop that picks up all GUI events and then dispatches
> them. It’s part of NextStep. It’s unclear to me why it’s run in
> ns_select, but presumably it’s because it needs to be run somewhere
> and whoever wrote it thought that was a good place.
>
> If we need to, I expect we could move it to its own thread. That seems
> to be a known pattern in the GNUStep/Cocoa world.
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?
> I’m pretty sure that Emacs doesn’t even use ns_select when it’s run
> in the terminal, though.
Actually, I think it has to use ns_select, because subprocesses are
still supported on a text terminal, and reading their output calls
ns_select. Likewise network connections.
- bug#25265: make-thread crashes in OS X 10.6, Charles A. Roelli, 2016/12/24
- bug#25265: make-thread crashes in OS X 10.6, Eli Zaretskii, 2016/12/24
- bug#25265: make-thread crashes in OS X 10.6, Eli Zaretskii, 2016/12/25
- bug#25265: make-thread crashes in OS X 10.6, Alan Third, 2016/12/26
- bug#25265: make-thread crashes in OS X 10.6, Eli Zaretskii, 2016/12/26
- bug#25265: make-thread crashes in OS X 10.6, Alan Third, 2016/12/26
- bug#25265: make-thread crashes in OS X 10.6, Eli Zaretskii, 2016/12/27
- bug#25265: make-thread crashes in OS X 10.6, Alan Third, 2016/12/27
- bug#25265: make-thread crashes in OS X 10.6,
Eli Zaretskii <=
- bug#25265: make-thread crashes in OS X 10.6, Alan Third, 2016/12/28
- bug#25265: make-thread crashes in OS X 10.6, Eli Zaretskii, 2016/12/29
- bug#25265: make-thread crashes in OS X 10.6, Alan Third, 2016/12/30
- bug#25265: make-thread crashes in OS X 10.6, Eli Zaretskii, 2016/12/30
- bug#25265: make-thread crashes in OS X 10.6, Alan Third, 2016/12/30
- bug#25265: make-thread crashes in OS X 10.6, Eli Zaretskii, 2016/12/31
- bug#25265: [PATCH] Rework NS event handling (bug#25265), Alan Third, 2016/12/31
- bug#25265: [PATCH] Rework NS event handling (bug#25265), Eli Zaretskii, 2016/12/31
- bug#25265: [PATCH] Rework NS event handling (bug#25265), Alan Third, 2016/12/31