Re: semantics of thread-signal (WAS: Crashing the new thread code)

[Noam Postavsky <npostavs@users.sourceforge.net>]

On Sun, Dec 11, 2016 at 5:56 PM, Juliusz Chroboczek <jch@irif.fr> wrote:
>> 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.

I'm not sure either, my expectations are shaped by experience with
non-Emacs thread code.

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

My interpretation is that mutex-lock (and the others) block the thread
until something happens (e.g., another thread calls mutex-unlock), and
thread-signal is another thing which can end the blocking (and also
trigger a signal when the thread next runs).

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

This can't happen, because thread are cooperative. i.e., only one
thread runs at a time.