[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-gnubg] Multiprocessing and remote processing committed to CVS
From: |
Olivier Baur |
Subject: |
Re: [Bug-gnubg] Multiprocessing and remote processing committed to CVS |
Date: |
Sat, 31 May 2003 03:52:14 +0200 |
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
- [Bug-gnubg] Multiprocessing and remote processing committed to CVS, Olivier Baur, 2003/05/30
- Re: [Bug-gnubg] Multiprocessing and remote processing committed to CVS, Joern Thyssen, 2003/05/30
- Re: [Bug-gnubg] Multiprocessing and remote processing committed to CVS, Holger, 2003/05/30
- Re: [Bug-gnubg] Multiprocessing and remote processing committed to CVS, Joern Thyssen, 2003/05/30
- Re: [Bug-gnubg] Multiprocessing and remote processing committed to CVS, Joern Thyssen, 2003/05/31
- Re: [Bug-gnubg] Multiprocessing and remote processing committed to CVS, Joern Thyssen, 2003/05/31
- Re: [Bug-gnubg] Multiprocessing and remote processing committed to CVS, Olivier Baur, 2003/05/31
- Re: [Bug-gnubg] Multiprocessing and remote processing committed to CVS, Joern Thyssen, 2003/05/31
- Re: [Bug-gnubg] Multiprocessing and remote processing committed to CVS, Olivier Baur, 2003/05/31
- Re: [Bug-gnubg] Multiprocessing and remote processing committed to CVS, Joern Thyssen, 2003/05/31
- Re: [Bug-gnubg] Multiprocessing and remote processing committed to CVS, Joern Thyssen, 2003/05/31