[Bug-gnubg] redesign gnubg to master/slave

[Joern Thyssen]

Hi all,

One of the recent topics has been multi-threading. Instead of
multi-threading Jim suggested splitting gnubg into a GUI (master) and an
engine (slave) which communicates over sockets.

Besides avoiding the problem of making the engine of gnubg thread-safe
it also follows the Unix design principles
(http://www.catb.org/~esr/writings/taoup/html), i.e.,
http://www.catb.org/~esr/writings/taoup/html/ch11s06.html.

I would like to start a discussion on how to do this. 

How should the split be? Should the slave only be capable of doing
evaluations and rollouts, or should it implement match-analysis as well?
Without much prior thought I'd say only evaluations and rollouts, but
I'm a bit worried about the overhead for a 0-ply match analysis. Also,
what about move analysis?

I guess the best is a stateless interface, e.g., an example could be:

evaluation 4HPwATDgc/ABMA cIkUAAAAAAAA 2-ply cubeful

which replies

evaluation-result 0.519 0.148 0.006 0.128 0.005 +0.060 +0.077 

Rollouts (and possibly high-ply evaluations) would send back multiple
lines so the GUI can show progress.

Any thoughts on this?

Jørn

pgpva5xPPAWga.pgp
Description: PGP signature