DDD 3.3.11 burning more CPU than it should on startup

[Doug Graham]

The problem is that ddd_setup_done is being installed as a workproc via
XtAppAddWorkProc(), but it may have to wait a while for GDB to become
ready.  While DDD is waiting, it is calling ddd_setup_done repeatedly,
thus hogging the CPU.  And since it is hogging CPU, it is slowing
down GDB, which then takes a lot longer to initialize than it otherwise
would.

This problem is especially noticable when ddd is started with a
"-x <script>" option.  In my case, the script does:

   file <executable>
   set args <...>
   set some breakpoints

and I start ddd with only the -x option (no executable specified on the
command line).  It takes GDB about 10 seconds of CPU to do an initial scan
of the executable, and during this time, ddd burns about a minute of CPU.

I don't think workprocs are designed to be used to poll for external
events like this; they are meant to be used to do finite amounts of work
in the background.

Replacing XtAppAddWorkProc() with XtAppAddTimeOut() and a 10ms polling
period works well as a solution.  There are 3 or 4 other uses of
XtAppAddWorkProc() that are also suspect.

This occurs on RedHat 7.3 systems and on RHEL 3 systems, and probably
all versions of Linux and perhaps other systems too.

   % ddd --configuration
   GNU DDD 3.3.11 (i686-pc-linux-gnu)
   Copyright (C) 1995-1999 Technische Universitdt Braunschweig, Germany.
   Copyright (C) 1999-2001 Universitdt Passau, Germany.
   Copyright (C) 2001 Universitdt des Saarlandes, Germany.
   Copyright (C) 2001-2004 Free Software Foundation, Inc.
   
   Compiled with GCC 3.4.1, GNU libc 2.2
   Requires X11R6, Xt11R6, Motif 2.2.3 (Motif Version 2.2.2)
   Includes XPM 3.4.11, Athena Panner (7000002L), DDD core

A (hacked up) patch for the ddd_setup_done instance of XtAppAddWorkProc()
follows.

*** mainloop.C  2005/11/20 06:19:08     1.1
--- mainloop.C  2005/11/20 09:19:54
  
+ /*
+  * Wrap ddd_setup_done so we can install it as a timer rather than a
+  * workproc.  It seems that workprocs on Linux burn a lot of CPU
+  * and starve GDB
+  */
+ static void wrap_ddd_setup_done(XtPointer, XtIntervalId *)
+ {
+     if (!ddd_setup_done(0))
+       XtAppAddTimeOut(XtWidgetToApplicationContext(gdb_w), 10, 
wrap_ddd_setup_done, 0);
+ }
+ 
  // DDD main loop.  This is placed in a separate module to avoid
  // warnings about longjmp() clobbering local variables.
  void ddd_main_loop()
***************
*** 95,101 ****
--- 108,125 ----
  
      // Set `main_loop_entered' to true as soon 
      // as DDD becomes idle again.
+ 
+     // Something about Linux's implementation of workprocs makes them burn
+     // a lot of CPU, which has the nasty side effect of slowing down the
+     // app we're waiting for (GDB), which has the nasty side effect of
+     // giving us more time to burn even more CPU.  So don't use workprocs.
+     // We'll poll ddd_setup_done every 10ms instead of the bazillion times
+     // per second that it as being polled via the workproc.
+ #ifdef original
      XtAppAddWorkProc(XtWidgetToApplicationContext(gdb_w), ddd_setup_done, 0);
+ #else
+     XtAppAddTimeOut(XtWidgetToApplicationContext(gdb_w), 10, 
wrap_ddd_setup_done, 0);
+ #endif
  
      // Main Loop
      for (;;)

--Doug.