[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug-gnubg] redesign gnubg to master/slave

From: Joern Thyssen
Subject: [Bug-gnubg] redesign gnubg to master/slave
Date: Sun, 21 Dec 2003 19:54:17 +0000
User-agent: Mutt/1.4.1i

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.,

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?


Attachment: pgpva5xPPAWga.pgp
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]