Delivered-To: garrigue at math.nagoya-u.ac.jp Delivered-To: lablgtk at yquem.inria.fr From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: lablgtk at yquem.inria.fr Subject: Re: [Lablgtk] Threading woes Date: Sun, 7 Feb 2010 02:15:38 +0000 References: <201002060530.16615.jon at ffconsultancy.com> <20100206.142508.58450194.garrigue@math.nagoya-u.ac.jp> <201002062304.47119.jon@ffconsultancy.com> In-Reply-To: <201002062304.47119.jon at ffconsultancy.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201002070215.38849.jon at ffconsultancy.com> Cc: Jacques Garrigue Status: U On Saturday 06 February 2010 23:04:47 Jon Harrop wrote: > Ok. That gets the program to run but it just recovers the original problem: > once the GUI starts my worker thread barely gets scheduled and little > computation gets done but the whole app burns 100% CPU. > > I guess either my code is just too slow or all the time is being spent > redrawing in the GUI thread and I need to yield the UI thread or redraw > after a timeout. I chose the latter solution and it has indeed fixed the problem. For some reason no time was given to the worker thread while the UI thread redundantly redrew, burning 100% CPU. Using a timeout to redraw only every 30ms frees the program up to put a decent proportion of the CPU time into the worker thread. This is an interesting problem that I had not come across in the original F# code for two reasons: 1) the worker thread got its own core whereas OCaml's global lock put threads in competition for time even when cores are idle, and 2) UI redraws occur at most every vsync in WPF whereas GTK allows redraws to spin and lock up the application. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e _______________________________________________ Lablgtk mailing list Lablgtk@yquem.inria.fr http://yquem.inria.fr/cgi-bin/mailman/listinfo/lablgtk