bug-gnubg
[Top][All Lists]
Advanced

[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.
[snip]

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.

Jørn

Attachment: pgperw9KuxurD.pgp
Description: PGP signature


reply via email to

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