GNU bug report logs - #79334
[PATCH] Don't release thread select lock unnecessarily

Previous Next

Full log

Message #35 received at 79334 <at> debbugs.gnu.org (full text, mbox):

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79334 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu, Dmitry Gutov <dmitry <at> gutov.dev>
Subject: Re: bug#79334: [PATCH] Don't release thread select lock unnecessarily
Date: Fri, 29 Aug 2025 12:11:02 -0400

[Message part 1 (text/plain, inline)]

On Fri, Aug 29, 2025, 11:57 AM Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Spencer Baugh <sbaugh <at> janestreet.com>
> > Date: Fri, 29 Aug 2025 11:43:21 -0400
> > Cc: 79334 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu, Dmitry Gutov <
> dmitry <at> gutov.dev>
> >
> > Okay, so then how about we delete this unsafe thread_select and put some
> thread-yield calls around
> > wait_reading_process_output?
>
> I'm not objected to not calling thread_select there, but can we have
> tests that will show us the gains?
>

The primary gain is that it becomes easier to reason about locking.  I'm
not sure how to write a test for that :)

Also, I think we should fix the problems with status_notify and other
> users of FOR_EACH_PROCESS before we make the change with
> thread_select, because current code in status_notify is definitely
> wrong, and affects the related behavior.
>

Yes, I'll work on a patch which does both.  (I'm not going to bother making
a change which doesn't rely on the change to remove the thread_select,
because this code is hard enough to reason about already)

>

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.