[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.
[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
pgperw9KuxurD.pgp
Description: PGP signature