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

[Pedro Alves]

On 2022-07-11 6:50 p.m., Eli Zaretskii wrote:
>> Cc: gdb-patches@sourceware.org
>> From: Pedro Alves <pedro@palves.net>
>> Date: Mon, 11 Jul 2022 18:48:19 +0100
>>
>>> But that is too far: it comes after you tell how the replay mode
>>> behaves, which is a separate issue.  So if you want to say it once for
>>> both ON and STEP values, I suggest to say something like
>>>
>>>   Both the @code{on} and @code{step} settings hold stopped any new
>>>   threads created by the resumed thread.
>>>
>>> before you describe how the rep[lay mode behaves.
>>>
>>
>> I don't see it as a separate issue.  The last sentence just before mine says:
>>
>>  "The @code{replay} mode behaves like @code{off} in record mode and like
>>  @code{on} in replay mode."
>>
>> I.e., the scheduler is locked in replay mode.  This is another case of
>> scheduler-locking being in effect.
> 
> Fine, but is something wrong with the text I proposed?
> 

Yes, you said to put it before the description of how the replay mode behaves,
and your text implies the change only affects "on" and "step", while it
affects "replay" as well.  As I said, the change affects all cases of
actually locking the scheduler, so it is not appropriate to single out just
some modes.