* Crashing the new thread code
@ 2016-12-11 18:37 Juliusz Chroboczek
2016-12-11 20:34 ` Eli Zaretskii
0 siblings, 1 reply; 8+ messages in thread
From: Juliusz Chroboczek @ 2016-12-11 18:37 UTC (permalink / raw
To: emacs-devel
Running 26.0.50.7 on Linux/AMD64. The following immediately crashes
Emacs:
(let ((thread (make-thread #'(lambda () (while t (thread-yield))))))
(thread-signal thread 'error nil))
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Crashing the new thread code
2016-12-11 18:37 Crashing the new thread code Juliusz Chroboczek
@ 2016-12-11 20:34 ` Eli Zaretskii
2016-12-11 21:22 ` Juliusz Chroboczek
0 siblings, 1 reply; 8+ messages in thread
From: Eli Zaretskii @ 2016-12-11 20:34 UTC (permalink / raw
To: Juliusz Chroboczek; +Cc: emacs-devel
> From: Juliusz Chroboczek <jch@irif.fr>
> Date: Sun, 11 Dec 2016 19:37:09 +0100
>
> Running 26.0.50.7 on Linux/AMD64. The following immediately crashes
> Emacs:
>
> (let ((thread (make-thread #'(lambda () (while t (thread-yield))))))
> (thread-signal thread 'error nil))
What is the semantics of signaling a thread that yields? What did you
expect to happen? Of course, Emacs shouldn't exit, but what should it
do in this case?
Thanks.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Crashing the new thread code
2016-12-11 20:34 ` Eli Zaretskii
@ 2016-12-11 21:22 ` Juliusz Chroboczek
2016-12-11 21:58 ` Noam Postavsky
0 siblings, 1 reply; 8+ messages in thread
From: Juliusz Chroboczek @ 2016-12-11 21:22 UTC (permalink / raw
To: emacs-devel; +Cc: Eli Zaretskii
>> The following immediately crashes Emacs:
>>
>> (let ((thread (make-thread #'(lambda () (while t (thread-yield))))))
>> (thread-signal thread 'error nil))
> What is the semantics of signaling a thread that yields?
I'm not sure, that's why I was experimenting.
> What did you expect to happen?
The thread queues the condition and continues spinning?
> Of course, Emacs shouldn't exit, but what should it do in this case?
The condition is queued forever? On the one hand, conditions should
only be delivered in well-defined circumstances (or else unwind-protect
becomes unusable), on the other hand, I expect asynchronous signal
delivery to be reliable.
(Is the set of functions that deliver a condition is too restrictive?
I see no way to check for a queued condition without grabbing a lock.)
-- Juliusz
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Crashing the new thread code
2016-12-11 21:22 ` Juliusz Chroboczek
@ 2016-12-11 21:58 ` Noam Postavsky
2016-12-11 22:56 ` Juliusz Chroboczek
2016-12-12 3:41 ` Eli Zaretskii
0 siblings, 2 replies; 8+ messages in thread
From: Noam Postavsky @ 2016-12-11 21:58 UTC (permalink / raw
To: Juliusz Chroboczek; +Cc: Eli Zaretskii, Emacs developers
On Sun, Dec 11, 2016 at 4:22 PM, Juliusz Chroboczek <jch@irif.fr> wrote:
>>> The following immediately crashes Emacs:
>>>
>>> (let ((thread (make-thread #'(lambda () (while t (thread-yield))))))
>>> (thread-signal thread 'error nil))
>
>> What is the semantics of signaling a thread that yields?
>
> I'm not sure, that's why I was experimenting.
>
>> What did you expect to happen?
>
> The thread queues the condition and continues spinning?
I would expect the thread to receive the signal as soon as it starts
running again.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Crashing the new thread code
2016-12-11 21:58 ` Noam Postavsky
@ 2016-12-11 22:56 ` Juliusz Chroboczek
2016-12-12 3:41 ` Eli Zaretskii
1 sibling, 0 replies; 8+ messages in thread
From: Juliusz Chroboczek @ 2016-12-11 22:56 UTC (permalink / raw
To: emacs-devel
> I would expect the thread to receive the signal as soon as it starts
> running again.
I'm not sure what the semantics of signal-thread is supposed to be. The
manual says:
‘thread-signal’ will cause a thread to exit a call to ‘mutex-lock’,
‘condition-wait’, or ‘thread-join’.
I assumed this to mean that the condition will only be delivered when
one of these functions is called, but your comment seems to imply that
it's meant to deliver the condition as soon as possible.
Which makes sense, but gives a whole new flavour to using unwind-protect
now that conditions can be signalled asynchronously.
(Aside: I'm actually not quite sure in that case that unwind-protect can
be used safely at all. What happens if a condition is signalled during
the cleanup? Say:
(let ((foo nil))
(unwind-protect
(progn
(setq foo (make-foo))
(do-stuff-with foo))
(when foo (destroy-foo foo))))
if a condition is signalled just before the cleanup but after exiting
the body, will we leak a foo? End of aside.)
-- Juliusz
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Crashing the new thread code
2016-12-11 21:58 ` Noam Postavsky
2016-12-11 22:56 ` Juliusz Chroboczek
@ 2016-12-12 3:41 ` Eli Zaretskii
2016-12-12 4:10 ` Noam Postavsky
1 sibling, 1 reply; 8+ messages in thread
From: Eli Zaretskii @ 2016-12-12 3:41 UTC (permalink / raw
To: Noam Postavsky; +Cc: jch, emacs-devel
> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Date: Sun, 11 Dec 2016 16:58:49 -0500
> Cc: Emacs developers <emacs-devel@gnu.org>, Eli Zaretskii <eliz@gnu.org>
>
> >> What did you expect to happen?
> >
> > The thread queues the condition and continues spinning?
>
> I would expect the thread to receive the signal as soon as it starts
> running again.
What would be the indication of the thread receiving the signal? Both
in general and specifically in Juliusz's snippet?
Please note that the current implementation effectively makes non-main
threads run with all errors caught, so signaling an error has much
less spectacular consequences than in the main thread.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Crashing the new thread code
2016-12-12 3:41 ` Eli Zaretskii
@ 2016-12-12 4:10 ` Noam Postavsky
2016-12-12 17:11 ` Eli Zaretskii
0 siblings, 1 reply; 8+ messages in thread
From: Noam Postavsky @ 2016-12-12 4:10 UTC (permalink / raw
To: Eli Zaretskii; +Cc: Juliusz Chroboczek, Emacs developers
On Sun, Dec 11, 2016 at 10:41 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Noam Postavsky <npostavs@users.sourceforge.net>
>> Date: Sun, 11 Dec 2016 16:58:49 -0500
>> Cc: Emacs developers <emacs-devel@gnu.org>, Eli Zaretskii <eliz@gnu.org>
>>
>> >> What did you expect to happen?
>> >
>> > The thread queues the condition and continues spinning?
>>
>> I would expect the thread to receive the signal as soon as it starts
>> running again.
>
> What would be the indication of the thread receiving the signal? Both
> in general and specifically in Juliusz's snippet?
In general, that any condition-case or unwind-protect forms should
run. Since Juliusz's snippet had no other signal catching constructs,
the signaled thread would just exit, I suppose.
>
> Please note that the current implementation effectively makes non-main
> threads run with all errors caught, so signaling an error has much
> less spectacular consequences than in the main thread.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Crashing the new thread code
2016-12-12 4:10 ` Noam Postavsky
@ 2016-12-12 17:11 ` Eli Zaretskii
0 siblings, 0 replies; 8+ messages in thread
From: Eli Zaretskii @ 2016-12-12 17:11 UTC (permalink / raw
To: Noam Postavsky; +Cc: jch, emacs-devel
> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Date: Sun, 11 Dec 2016 23:10:48 -0500
> Cc: Juliusz Chroboczek <jch@irif.fr>, Emacs developers <emacs-devel@gnu.org>
>
> On Sun, Dec 11, 2016 at 10:41 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> >> From: Noam Postavsky <npostavs@users.sourceforge.net>
> >> Date: Sun, 11 Dec 2016 16:58:49 -0500
> >> Cc: Emacs developers <emacs-devel@gnu.org>, Eli Zaretskii <eliz@gnu.org>
> >>
> >> >> What did you expect to happen?
> >> >
> >> > The thread queues the condition and continues spinning?
> >>
> >> I would expect the thread to receive the signal as soon as it starts
> >> running again.
> >
> > What would be the indication of the thread receiving the signal? Both
> > in general and specifically in Juliusz's snippet?
>
> In general, that any condition-case or unwind-protect forms should
> run. Since Juliusz's snippet had no other signal catching constructs,
> the signaled thread would just exit, I suppose.
OK, this is how the latest master will behave.
The original problem happened because the new thread was trying to
signal itself before the signal handlers were set up, and actually
before the thread function was even running.
Thanks.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2016-12-12 17:11 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-12-11 18:37 Crashing the new thread code Juliusz Chroboczek
2016-12-11 20:34 ` Eli Zaretskii
2016-12-11 21:22 ` Juliusz Chroboczek
2016-12-11 21:58 ` Noam Postavsky
2016-12-11 22:56 ` Juliusz Chroboczek
2016-12-12 3:41 ` Eli Zaretskii
2016-12-12 4:10 ` Noam Postavsky
2016-12-12 17:11 ` Eli Zaretskii
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.