Hi, Thanks for your reply and suggestion!! 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? Thanks, Sorin On Wed, Dec 3, 2008 at 12:07 AM, Cai Qiang <[EMAIL PROTECTED]> wrote: > Hi, > > Why do you need "a new process is spawned on each move "? Don't we just > need to spawn one process for each game? > > I have used Gnugo for a while on my Go website http://www.361points.com to > allow people to play online against Gnugo. > The way I used it was to use GTP between Python (which my website is built > upon for the dynamic content) and a Gnugo executable on Linux. > Once this became popular, the fact that a new process is spawned on each > move because a big scalability bottleneck. > > > > _______________________________________________ > gnugo-devel mailing list > gnugo-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/gnugo-devel > >
_______________________________________________ gnugo-devel mailing list gnugo-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gnugo-devel
