Re: [Bug-gnubg] Multiprocessing and remote processing committed to CVS

[Olivier Baur]

Le samedi, 31 mai 2003, à 00:01 Europe/Paris, Joern Thyssen a écrit :

> I've managed to compile it (there is a bit C++ specific code that gcc
> doesn't like).

C++ specific code?

Could you try it on a multiprocessor machine or with remote slave 
hosts? (in tty mode)

Starter info:
- the multiprocessor and remote processing mechanism is implemented as 
"processing units" ("pu" for short)
- procunits can be either local (1 per processor) or remote (1 per 
remote host); each remote host in turn can sport several local and 
remote procunits
- all commands related to procunits are "pu <sub-command>", "set pu 
<sub-command>" or "show pu <sub-command>"; gnubg "help" will give more 
details;
- type "pu add local" to add an extra local procunit (1 is created by 
default at gnubg startup time; if the GetProcessorsCount() in 
procunits.c is properly implemented for your system, gnubg will create 
as many local procunits as there are processors)
- type "pu add remote a.b.c.d" to add a remote procunit; the remote 
procunit must be running gnubg in slave mode on host at ip address 
a.b.c.d
- to run gnubg in slave mode, type "pu slave"
- other useful commands: "show pu info" (or "pu info"), "show pu 
stats", "pu start <id>" and "pu stop <id>"


> I get some weird GTK+ warnings when I start it:
>
> ** (gnubg:11058): WARNING **: Invalid UTF8 string passed to 
> pango_layout_set_text()

> It looks like there is a memory leak somewhere. Is this the kind of
> problems you see too?

No, I don't get this message.
Everything looks okay when I launch gnubg. Things start to go wrong 
when I start threads (ie, start a rollout), and I get things like:
>> (gnubg:15282): GLib-WARNING **: g_main_context_prepare(): main loop 
already active in another thread
>> Xlib: unexpected async reply (sequence 0x29bc)!

I've not been looking for memory leaks recently (since I found the one 
that leaked about 10 MB / sec!)

What is strange in your test is that, as long as you don't install 
remote processing units or start a rollout, gnubg won't launch any new 
thread; so, till then, you must be running in a single-thread process 
as usual...


> BTW, did you read:
>
> http://developer.gnome.org/doc/API/2.0/gdk/gdk-Threads.html

Yes, I have just stepped accross this page yesterday, and I have tried 
to use the thread-protection functions offered in GDK, but without 
success -- couldn't compile, GDK header file problems in my distrib it 
seems, had not enough time at the moment to start parsing all GTK/GDK 
header files :-)
I need to have a deeper look at the issue, because I feel the cure 
offered by the GDK doc matches the above symptoms ("main loop already 
active in other thread", "unexpected async reply")


Best,

-- Olivier