Re: [Bug-gnubg] redesign gnubg to master/slave

[Holger]

At 20:54 21.12.2003, Joern Thyssen wrote:
> 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
>
> I would like to start a discussion on how to do this.

As I already mentioned some days ago Olivier Baur has implemented all these 
things already in the branch-multi branch. See 
http://mapage.noos.fr/gnubgosx/procunits.html . This works very well with 
the CLI version, but even has an easy to use GUI frontend. "help" will tell 
you the necessary commands. On this page only the setup through the GUI is 
described.

> 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?

Imho the tasks (remote or local) should be "big" enough that the protocol 
overhead is neglectable, but "small" enough so that the machines/processors 
are equally supplied with tasks and all tasks have a similar execution time.
So a 0-ply analysis of one single move/cube decision is no candidate, but 
2-ply could already be. This could even be set with a user definable filter.

> 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

I think something along these lines is done, but probably on a slightly 
lower level.

Btw, in case this CVS branch is not accessible I could send you a copy of 
the latest checkout.

Regards,

        Holger