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

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Spencer Baugh <sbaugh <at> janestreet.com>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 79334 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu
Subject: bug#79334: [PATCH] Don't release thread select lock unnecessarily
Date: Sun, 31 Aug 2025 06:20:24 +0300

On 29/08/2025 19:11, Spencer Baugh wrote:
> On Fri, Aug 29, 2025, 11:57 AM Eli Zaretskii <eliz <at> gnu.org 
> <mailto:eliz <at> gnu.org>> wrote:
> 
>      > From: Spencer Baugh <sbaugh <at> janestreet.com
>     <mailto:sbaugh <at> janestreet.com>>
>      > Date: Fri, 29 Aug 2025 11:43:21 -0400
>      > Cc: 79334 <at> debbugs.gnu.org <mailto:79334 <at> debbugs.gnu.org>,
>     eggert <at> cs.ucla.edu <mailto:eggert <at> cs.ucla.edu>, Dmitry Gutov
>     <dmitry <at> gutov.dev <mailto: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 :)

I think what could help in this area is some benchmarking scenario, and 
the goal would be to show that it doesn't regress (or within the margin 
of error) when 'pselect' is used directly.

A script which would create a bunch of threads and some amount of 
processes spawned by them with certain characteristics. Depending on 
what workload switching in that thread_select could help optimize.

Previous Next

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