[Top][All Lists]

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

Re: Réf? . : Re: [Bug-gnubg] Tutor/Analysis

From: Joern Thyssen
Subject: Re: Réf? . : Re: [Bug-gnubg] Tutor/Analysis
Date: Fri, 3 Oct 2003 13:58:15 +0000
User-agent: Mutt/1.4.1i

On Fri, Oct 03, 2003 at 03:31:29PM +0200, Jim Segrave wrote
> On Fri 03 Oct 2003 (13:44 +0200), Nardy Pillards wrote:
> I'm less pessimistic than Joern, I think it's possible that after the
> storage of move records has had some rework it may eventually be
> possible to do this. 
> While writing this, another approach has occurred to me which is
> either kind of slick or horribly awful:
> [warning - delving off into technical issues here, backgammon players
> need not read further]
> Suppose one didn't try to thread gnubg, but instead (when auto-analyse
> is selected) simply forked when starting a match or session. The child
> process would be the analyser and would do whatever's needed to close
> any gui or cli interfaces.
> Have a shared memory segment for completed moves, so when the playing
> side of gnubg was ready to add a move to the list, it obtained a lock,
> added the move and released it. Moves are only written by the parent
> process except at very specific times when copying the analysis
> results back to the parent.

Your suggestion is basically some async master/slave process:

The master request an analysis from the slave
The master goes on doing what it needs to do
The master asks for the previous analysis and requests a new one

The alternative way is having a thread that sneaks around and analyses
any un-analysed moverecords.


Attachment: pgperw9KuxurD.pgp
Description: PGP signature

reply via email to

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