Re: [Bug-gnubg] Multiprocessing and GDK

[Olivier Baur]

Le vendredi, 6 juin 2003, à 10:57 Europe/Paris, Joern Thyssen a écrit :

> Did you manage to commit your changes?

I've just commited my changes.

Things done:
* Fixed problems which prevented from compiling with PROCESSING_UNITS 
defined to 0.
* Added some GDK/GTK thread support.
* Redesigned RPU messaging mechanism -- now struct alignment safe and 
big/little-endian safe (but will need some testing)
* Started implementing analysis distributed processing.
* Added support for hostnames:port syntax when creating remote 
processing units, eg "myhost.gnu.org:1000"

I actually still have problems with GTK.

* Since I've added g_thread_init() and 
gtk_thread_enter()/gtk_thread_leave() around the main gtk_main() call, 
I don't get any crashes or deadlocks anymore;
* However, during a rollout, the progress window pops up, the rollout 
info are updated for each new played rollout game, BUT the controls 
(buttons, frames, progress bar, etc) are not drawn, and I can't click 
the "Stop" button (which I can't see); when the full rollout is 
completed, the controls are eventually drawn to the screen and the 
buttons are active again;
* I know the fnAction callback is called from the threads that compute 
rollouts, but they don't seem to see any pending events (there should 
be "draw" or "update" events pending since the progress window has been 
created) and so gtk_main_iteration() never gets called;
* I've been able to get around this by not calling fnAction from the 
rollout threads anymore, but from the main thread (the one that 
dispatches tasks and collects results); it works, but with a big lag 
(for example, hovering the mouse over a button will highlight it only 
when fnAction gets called, not in "real time" as with the non-threaded 
version);
--> Can anyone explain me why we don't get any lag without threads, 
when it looks to me that even in the standard, one-thread version, the 
fnAction callback gets called only when gnubg yields time to GTK 
through a gtk_main_iteration() call? I'm sure there's something I've 
missed...


-- Olivier