[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.,
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
- [Bug-gnubg] redesign gnubg to master/slave,
Joern Thyssen <=