Hi,
Yes, "spawn one process for each game" method averagely will use more memory
than "spawn one process for each move". But if "The complain from my ISV was
about using to much CPU", your current "spawn one process for each move" uses
more CPU:
1. gnugo need to recalculate many info when you lose the previous
state(exit the gnugo) and let it genmove according a give position
2. the spawn/exit overhead
----- Original Message -----
From: Sorin Gherman
So your approach tries to minimize the number of time we open the gnugo
processes, on the other hand we'll still have the same number of processes
running, at any given time, as simultaneous players are there, and by keeping
them in memory we'll eat up more memory then in the current approach, with one
process opened per move.
The complain from my ISV was about using to much CPU (running too many gnugo
processes at the same time), which I don't think will change with one gnugo
process per player.
Back to my original question: I'm not even sure that the "calling gnugo as a
library from python" works, because the board is a global variable in gnugo, so
if I load the same library just once from the Python interpreter process, and
modify the board from different Python threads, they'll share and keep
modifying the same board structure, which is not good.
Can anyone comment on multithreaded issues that may occur in the "using gnugo
as a shared library" approach?
_______________________________________________
gnugo-devel mailing list
gnugo-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/gnugo-devel
