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?