Re: [PATCH 19/25] Don't resume new threads if scheduler-locking is in effect

[Pedro Alves <pedro@palves.net>]

Hi,

On 2022-06-21 12:07 p.m., Eli Zaretskii wrote:
>> From: Pedro Alves <pedro@palves.net>
>> Date: Mon, 20 Jun 2022 23:54:13 +0100
>>
>> diff --git a/gdb/NEWS b/gdb/NEWS
>> index 5576c355b7a..2e842cb00f9 100644
>> --- a/gdb/NEWS
>> +++ b/gdb/NEWS
>> @@ -3,6 +3,9 @@
>>  
>>  *** Changes since GDB 12
>>  
>> +* If supported by the target, when scheduler-locking is in effect, new
>> +  threads created by the resumed thread are held stopped.
>                         ^^^^^^^^^^^^^^^^^^
> "a resumed thread", I guess?

When scheduler locking is in effect, execution commands only resume one thread,
so "the" seems more correct to me.

I wrote the sentence in the manual first, before copying it here, and in the manual,
the text describing scheduler locking, above my new sentence says for example:

  "If @code{on}, then only the current thread may run when the inferior is resumed."

> 
>> diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
>> index b3e995f166b..775c4b1347b 100644
>> --- a/gdb/doc/gdb.texinfo
>> +++ b/gdb/doc/gdb.texinfo
>> @@ -6932,6 +6932,9 @@ current thread away from the thread that you are debugging.  The
>>  @code{replay} mode behaves like @code{off} in record mode and like
>>  @code{on} in replay mode.
>>  
>> +If supported by the target, when scheduler-locking is in effect, new
>> +threads created by the resumed thread are held stopped.
> 
> Same here, but maybe the following slight rewording will make the
> sentence simpler:
> 
>   When scheduler-locking is supported by the target and is in effect,
>   new threads created by a resumed thread are held stopped.
> 

Hmm, that is actually semantically different from what I intended.  I see the ambiguity,
but the part that I intended to cover with "if supported" is the hold-new-threads-stopped
part.  The intent is to document how targets ideally should behave when they implement
scheduler-locking.  However, not all targets that support scheduler locking
will hold new threads stopped, as this needs to be implemented on
the target/backend side.

I notice now that the whole "set scheduler-locking" description doesn't even
say that not all targets support scheduler locking.  Hmm.  How about I just
remove the "If supported by the target" part.  We can just consider that targets
that don't behave that way yet should be fixed (there's a new testcase that
will fail for such targets), while older GDBservers just can't ever be fixed,
but such is life of software progress.

> The documentation parts are okay with these nits fixed.
> 

How about this, then, given the explanations above?  Is it OK?

diff --git c/gdb/NEWS w/gdb/NEWS
index 1178a37017e..94553f18608 100644
--- c/gdb/NEWS
+++ w/gdb/NEWS
@@ -3,6 +3,9 @@
 
 *** Changes since GDB 12
 
+* When scheduler-locking is in effect, new threads created by the
+  resumed thread are held stopped.
+
 * "info breakpoints" now displays enabled breakpoint locations of
   disabled breakpoints as in the "y-" state.  For example:
 
diff --git c/gdb/doc/gdb.texinfo w/gdb/doc/gdb.texinfo
index 7a4e337d15b..fc297218696 100644
--- c/gdb/doc/gdb.texinfo
+++ w/gdb/doc/gdb.texinfo
@@ -6953,6 +6953,9 @@ current thread away from the thread that you are debugging.  The
 @code{replay} mode behaves like @code{off} in record mode and like
 @code{on} in replay mode.
 
+When scheduler-locking is in effect, new threads created by the
+resumed thread are held stopped.
+
 @item show scheduler-locking
 Display the current scheduler locking mode.
 @end table