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

[Eli Zaretskii]

> Cc: gdb-patches@sourceware.org
> From: Pedro Alves <pedro@palves.net>
> Date: Mon, 11 Jul 2022 17:38:48 +0100
> 
> >   @item set scheduler-locking @var{mode}
> >   @cindex scheduler locking mode
> >   @cindex lock scheduler
> >   Set the scheduler locking mode.  It applies to normal execution,
> >   record mode, and replay mode.  If it is @code{off}, then there is no
> >   locking and any thread may run at any time.  If @code{on}, then only
> >   the current thread may run when the inferior is resumed; even threads
> >   created by the resumed thread are held stopped.          ^^^^^^^^^^^^
> >   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > 
> > And now I wonder what happens when scheduler-locking is set to 'step':
> > are new threads created by the resumed thread held stopped as in the
> > ON case?
> > 
> 
> Yes, they are.  That's why I put the new sentence at the end and not connected to "on",
> and  said "is in effect", not "on".  I.e., when the scheduler is actually locked.

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.