Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Pedro Alves <pedro@codesourcery.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [RFC] Allowing all threads of all|current process(es) to be resumed [new command + docs]
Date: Tue, 09 Jun 2009 04:01:00 -0000	[thread overview]
Message-ID: <E1MDsWc-0006so-BA@fencepost.gnu.org> (raw)
In-Reply-To: <200906081259.54338.pedro@codesourcery.com> (message from Pedro 	Alves on Mon, 8 Jun 2009 12:59:53 +0100)

> From: Pedro Alves <pedro@codesourcery.com>
> Date: Mon, 8 Jun 2009 12:59:53 +0100
> 
> On Saturday 30 May 2009 18:12:09, Eli Zaretskii wrote:
> 
> > Thanks, the new patch for the manual and the NEWS entry are fine with
> > me, but please consider the two remaining issues mentioned above.
> 
> Certainly!  I'd really like you to be happy with this and here's my
> next attempt at that.  I've given a short example of why you'd want
> either behaviour; used "resuming the execution", and switched to
> mentioning the scheduler-locking precedence instead.

Thanks.

> +@cindex resume threads of multiple processes simultaneously
> +By default, @value{GDBN} allows only threads of the current inferior
> +to run in response to execution commands such as @code{continue},
> +@code{next} or @code{step}.  E.g., if @value{GDBN} is attached to two
> +inferiors, each with two threads, the @code{continue} command resumes
> +only the two threads of the current inferior.  This is useful for
> +example when debugging a program that forks, and you want to hold the
> +fork parent stopped (so that for instance it doesn't run to exit),
> +while debugging the child.  In other ocasions, you are not interested
> +in inspecting the current state of none of the processes @value{GDBN}
> +is attached to, and you want to resume them all until any reports a
> +breakpoint hit.  You can modify @value{GDBN}'s default behavior by
> +instead allowing all threads of all inferiors to run with the
> +@w{@code{set schedule-multiple}} command.

This is indeed what I had in mind, but the wording needs some
improvement.  I suggest this variant:

  By default, when you issue one of the execution commands such as
  @code{continue}, @code{next} or @code{step}, @value{GDBN} allows
  only threads of the current inferior to run.  For example, if
  @value{GDBN} is attached to two inferiors, each with two threads,
  the @code{continue} command resumes only the two threads of the
  current inferior.  This is useful, for example, when you debug a
  program that forks and you want to hold the parent stopped (so that,
  for instance, it doesn't run to exit), while you debug the child.
  In other situations, you may not be interested in inspecting the
  current state of any of the processes @value{GDBN} is attached to,
  and you may want to resume them all until some breakpoint is hit.
  In the latter case, you can instruct @value{GDBN} to allow all
  threads of all the inferiors to run with the @w{@code{set
  schedule-multiple}} command.

OK?

The rest of documentation-related hunks are fine with me.

Thanks.


  reply	other threads:[~2009-06-09  4:01 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-30 10:51 Pedro Alves
2009-05-30 13:10 ` Eli Zaretskii
2009-05-30 16:01   ` Pedro Alves
2009-05-30 17:12     ` Eli Zaretskii
2009-06-08 11:59       ` Pedro Alves
2009-06-09  4:01         ` Eli Zaretskii [this message]
2009-06-11 11:59           ` Pedro Alves
2009-05-31 16:34 ` Doug Evans
2009-05-31 16:40   ` Doug Evans
2009-05-31 18:31   ` Tom Tromey
2009-05-31 18:38     ` Doug Evans
2009-05-31 22:06     ` Pedro Alves
2009-06-01 15:55       ` Doug Evans
2009-06-03 14:06         ` Pedro Alves
2009-06-01 14:29 ` Marc Khouzam
2009-06-03 13:49   ` Pedro Alves

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=E1MDsWc-0006so-BA@fencepost.gnu.org \
    --to=eliz@gnu.org \
    --cc=gdb-patches@sourceware.org \
    --cc=pedro@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox