This is the mail archive of the
gdb-prs@sources.redhat.com
mailing list for the GDB project.
gdb/754: RDI code busy-waiting on running target?
- From: ac131313 at redhat dot com
- To: gdb-gnats at sources dot redhat dot com
- Date: 27 Sep 2002 22:39:01 -0000
- Subject: gdb/754: RDI code busy-waiting on running target?
- Reply-to: ac131313 at redhat dot com
>Number: 754
>Category: gdb
>Synopsis: RDI code busy-waiting on running target?
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Fri Sep 27 15:48:01 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator: ac131313@redhat.com
>Release: unknown-1.0
>Organization:
>Environment:
>Description:
See:
http://sources.redhat.com/ml/gdb-patches/2002-07/msg00256.html
Note that the original patch used ``usleep()'' instead of select() with a timer.
Andrew
Grant Edwards writes:
On Thu, Jul 11, 2002 at 05:58:56PM -0500, Grant Edwards wrote:
> I've noticed that gdb uses all the CPU it can get while the
> target is running (e.g. busy-waiting 'till target stops).
>
> I'm building 5.2 to see if it still does that
Yup.
Here's a patch that fixes it. I only added the usleep() when
there's no ui_loop_hook to call. Is that the right thing to
do, or will Insight et al still suck CPU time? I'm not sure
who's supposed to be surrendering the CPU, the UI or the
target.
Is usleep() portable?
--
Grant Edwards
grante@visi.com
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted: