Subject: Re: bug#79334: [PATCH] Don't release thread select lock unnecessarily

From: Dmitry Gutov <[email-masked]>
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 <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>      > From: Spencer Baugh <[email-masked]
>     <mailto:[email-masked]>>
>      > Date: Fri, 29 Aug 2025 11:43:21 -0400
>      > Cc: [email-masked] <mailto:[email-masked]>,
>     [email-masked] <mailto:[email-masked]>, Dmitry Gutov
>     <[email-masked] <mailto:[email-masked]>>
>      >
>      > 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.