I see, that makes a lot of sense, thanks again! As the game progresses, the load time for each new move will increase, I assume.So I agree now, keeping one process per game would benefit the CPU usage. Problem is that currently I don't have the notion of a "game" on the server side, but only on the client side. Also, there is no clear way to know that a game is over, and kill the associated gnugo process, without introducing some time limits for the user: have to close their game after N minutes of inactivity. Currently, without time limits, a user can, say take a lunch break and resume their game afterwards.
Sorin On Thu, Dec 4, 2008 at 12:35 AM, Cai Qiang <[EMAIL PROTECTED]> wrote: > 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 <[EMAIL PROTECTED]> > > 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 > >
_______________________________________________ gnugo-devel mailing list gnugo-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gnugo-devel
