Re: [RFC] Allowing all threads of all|current process(es) to be resumed [new command + docs]

[Eli Zaretskii <eliz@gnu.org>]

> From: Pedro Alves <pedro@codesourcery.com>
> Date: Sat, 30 May 2009 17:01:52 +0100
> Cc: marc.khouzam@ericsson.com
> 
> > Can you give at least 2 different use-cases, each one favoring one of
> > the possible behaviors?  I'm not sure I understand the nature of the
> > conflict.
> 
> As I've explained above.

Well, thanks, but your original explanation was clear enough.  What I
was asking for are use-cases where each of the two possible behaviors
would be preferable to the other.

> The conflict is that both "multi-process" implementations behave
> differently, and I'm getting rid of the multi-forks support as-is.

Sorry, I'm confused: if you are getting rid of multi-forks, won't the
conflict go away with it as well?

> Use case is "user wants to resume all processes" vs "user wants to
> resume only the current process".

Yes, but when would the latter be undesirable if the user uses
multi-forks?  If using multi-forks means the user will always want to
resume only the current process, we don't need the new option.

> > > +@cindex resume multiple processes
> > 
> > This index entry is too general.  I suggest something more specific to
> > the aspects you are describing.
> 
> Putting myself in a user's perspective, if I wanted to know how to
> resume multiple process simultaneously, I'd go look for resume, multiple,
> maybe I should add "simultaneously".  Did you have something
> completely different in mind?

You are not describing how to resume multiple process simultaneously.
You are describing how to control whether all of them or only one will
be resumed.

Your new index entry is fine.

> >   Set the mode for scheduling threads of multiple processes.
> > 
> > On second thought, "scheduling" is not the best word here, as GDB is
> > not a scheduler.  How about "continuing the execution"?
> 
> as in:
> 
>  Set the mode for continuing the execution of multiple processes.
> 
> ? I think that "continuing" may trigger confusion by making it
> look like only the "continue" command is affected.  See new patch below.

How about "resuming the execution", then?

> > > +The final set of threads that are allowed to run by execution commands
> > > +is defined by the union of the restrictions implied by both the
> > > +@code{schedule-multiple} and @code{scheduler-locking} modes.  E.g., if
> > > +the @code{schedule-multiple} mode is set to @code{on}, but the
> > > +scheduler locking mode is also set to @code{on}, then only the current
> > > +thread is made schedulable.
> > 
> > It might be easier and simpler to tell that scheduler-locking takes
> > precedence.
> 
> It does not really take scrict precedence, due to the "step" scheduler-locking
> variant.

You could say that it takes precedence when set to ON.

Thanks, the new patch for the manual and the NEWS entry are fine with
me, but please consider the two remaining issues mentioned above.