This is the mail archive of the gdb-prs@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

gdb/754: RDI code busy-waiting on running target?


>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:


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]