From: Eli Zaretskii <eliz@gnu.org>
To: dick <dick.r.chiang@gmail.com>
Cc: 51229@debbugs.gnu.org
Subject: bug#51229: 28.0.50; [PATCH] Mitigate Blandyism on thread signals
Date: Fri, 15 Oct 2021 22:11:32 +0300 [thread overview]
Message-ID: <83mtnahzmj.fsf@gnu.org> (raw)
In-Reply-To: <87r1cmjfye.fsf@dick> (message from dick on Fri, 15 Oct 2021 14:33:29 -0400)
> From: dick <dick.r.chiang@gmail.com>
> Date: Fri, 15 Oct 2021 14:33:29 -0400
>
> From: dickmao <dick.r.chiang@gmail.com>
> Date: Fri, 15 Oct 2021 14:29:17 -0400
> Subject: [PATCH] Blandyism #48
>
> As for most Blandyisms dating back to early 90s, the fastidious
> maintenance of the waiting_for_input flag likely yields no
> discernible difference at the cost of FUD.
>
> * src/thread.c (post_acquire_global_lock):
> Clear thread's "waiting_for_input" flag before signalling.
> ---
> src/thread.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/thread.c b/src/thread.c
> index 714b1cd903..d7dce6cc8e 100644
> --- a/src/thread.c
> +++ b/src/thread.c
> @@ -122,6 +122,7 @@ post_acquire_global_lock (struct thread_state *self)
>
> current_thread->error_symbol = Qnil;
> current_thread->error_data = Qnil;
> + clear_waiting_for_input();
> Fsignal (sym, data);
> }
That's a non-starter, not unless you explain why this is not needed
for threads, because it attempts to artificially remove a restriction
without any analysis or rationale. Why is a non-main thread waiting
for input different from the main thread waiting for input?
next prev parent reply other threads:[~2021-10-15 19:11 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-15 18:33 bug#51229: 28.0.50; [PATCH] Mitigate Blandyism on thread signals dick
2021-10-15 19:11 ` Eli Zaretskii [this message]
2021-10-16 11:52 ` Eli Zaretskii
2022-09-12 12:36 ` Lars Ingebrigtsen
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=83mtnahzmj.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=51229@debbugs.gnu.org \
--cc=dick.r.chiang@gmail.com \
/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.