From: Noam Postavsky <npostavs@users.sourceforge.net>
To: Juliusz Chroboczek <jch@irif.fr>
Cc: Emacs developers <emacs-devel@gnu.org>
Subject: Re: semantics of thread-signal (WAS: Crashing the new thread code)
Date: Sun, 11 Dec 2016 19:16:35 -0500 [thread overview]
Message-ID: <CAM-tV-9q_9pZuH4VQ0EeJ4NX1fudy9cZWepu9vrn7koN7U--YA@mail.gmail.com> (raw)
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.
next reply other threads:[~2016-12-12 0:16 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-12 0:16 Noam Postavsky [this message]
2016-12-12 1:21 ` semantics of thread-signal Juliusz Chroboczek
2016-12-12 2:06 ` Noam Postavsky
2016-12-12 16:08 ` Eli Zaretskii
2016-12-13 2:46 ` Noam Postavsky
2016-12-12 3:33 ` Eli Zaretskii
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=CAM-tV-9q_9pZuH4VQ0EeJ4NX1fudy9cZWepu9vrn7koN7U--YA@mail.gmail.com \
--to=npostavs@users.sourceforge.net \
--cc=emacs-devel@gnu.org \
--cc=jch@irif.fr \
/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.