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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: 79334 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu, dmitry <at> gutov.dev
Subject: bug#79334: [PATCH] Don't release thread select lock unnecessarily
Date: Fri, 29 Aug 2025 17:00:56 +0300

> From: Spencer Baugh <sbaugh <at> janestreet.com>
> Cc: 79334 <at> debbugs.gnu.org,  eggert <at> cs.ucla.edu,  dmitry <at> gutov.dev
> Date: Fri, 29 Aug 2025 09:45:07 -0400
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> That being said, I'm confident that it's incorrect and unnecessary to be
> >> using thread_select instead of pselect here, so we should stop doing
> >> that in addition to any other fix.
> >
> > If we fix status_notify, what other reasons remain for not calling
> > thread_select there?
> 
> Primarily: Calling thread_select here complicates reasoning about the
> code.  We should not release the lock when not necessary, because it
> makes it harder to think about possible thread interleavings.  And it's
> not necessary here because this pselect call returns immediately.

How do we define "necessary" in this context?

> (The only reason the pselect call wouldn't return immediately is if we
> released the lock and then switched to another thread)

You seem to assume that a call to thread_select is only necessary when
some potentially prolonged operation or wait is expected?  But I'm not
sure this is correct, because that could prevent other threads from
running for too long, and force programmers to inject sleep-for
etc. in their programs.  By allowing thread switches as frequently as
possible lets other threads more opportunities to run (to some extent
simulating preemptive scheduling), which I think is a Good Thing
overall, no?

Previous Next

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