CPU usage is high when there is an exception

Project:GNU Smalltalk
Component:VisualGST
Category:bug
Priority:normal
Assigned:bonzinip
Status:fixed
Description

When there is an exception in VisualGST gst uses 100% of the CPU.

To reproduce it this is simple in a workspace : self halt

Updates

#1 submitted by Paolo Bonzini on Wed, 11/18/2009 - 11:02

This would fix it:

diff --git a/packages/gtk/GtkImpl.st b/packages/gtk/GtkImpl.st
index 6a2d2fc..6097775 100644
--- a/packages/gtk/GtkImpl.st
+++ b/packages/gtk/GtkImpl.st
@@ -502,7 +502,7 @@ Gtk class extend [
         GTK.Gtk main: sem.
         sem wait.
         
-        [GTK.Gtk mainIterationDo: false.
+        [GTK.Gtk mainIterationDo: true.
         GTK.Gtk shouldQuit] 
                 whileFalse: [Processor yield]
     ]

but I have to check the impact on simulation speed (e.g. does moving the mouse increase the speed of simulation? that would be bad!). To fix it properly, the glib event loop should be hacked up to run the event loop together with Smalltalk code:

  1. Place the main loop at high priority and make it do something like this: 1) use g_main_context_set_poll_func and in the poll function set up SIGIO notification for the file descriptors, call g_main_context_pending to get this poll function called; 2) wait on a semaphore to be triggered by the SIGIO notifications; 3) revert to the default poll function and call g_main_context_iteration in non-blocking mode.
  2. Besides this, in sysdep/win32/events.c use MsgWaitForSingleObjects instead of WaitForSingleObject
#2 submitted by Paolo Bonzini on Fri, 11/27/2009 - 12:27
Priority:critical» normal
Assigned to:Unassigned» bonzinip
Status:active» postponed

Postponed to past 3.1.

#3 submitted by Gwenael Casaccio on Mon, 01/11/2010 - 09:34

diff --git a/packages/gtk/GtkImpl.st b/packages/gtk/GtkImpl.st
index 6a2d2fc..6097775 100644
--- a/packages/gtk/GtkImpl.st

+++ b/packages/gtk/GtkImpl.st

@@ -502,7 +502,7 @@ Gtk class extend [

        GTK.Gtk main: sem.
        sem wait.
        

- [GTK.Gtk mainIterationDo: false.

+ [GTK.Gtk mainIterationDo: true.

        GTK.Gtk shouldQuit] 
                whileFalse: [Processor yield]
    ]

This fix does not solve the problem

#4 submitted by Paolo Bonzini on Fri, 02/19/2010 - 08:55
Status:postponed» patch

Patches posted on the mailing list, only details missing.

#5 submitted by Paolo Bonzini on Sun, 05/02/2010 - 07:04
Status:patch» fixed

Fixed by new GTK+ event loop.

User login