Crashing the new thread code

Crashing the new thread code

[Juliusz Chroboczek]

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))

Re: Crashing the new thread code

[Eli Zaretskii]

> 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.

Re: Crashing the new thread code

[Juliusz Chroboczek]

>> 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

Re: Crashing the new thread code

[Noam Postavsky]

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.

Re: Crashing the new thread code

[Juliusz Chroboczek]

> 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

Re: Crashing the new thread code

[Eli Zaretskii]

> 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.

Re: Crashing the new thread code

[Noam Postavsky]

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.

Re: Crashing the new thread code

[Eli Zaretskii]

> 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.