[freeciv-ai] Re: FreeCiv brief analysis

[Raimar Falke <i-freeciv-lists@xxxxxxxxxxxxx>]

On Fri, Apr 02, 2004 at 09:17:03PM +0100, Vasco Alexandre Da Silva Costa wrote:
> On Fri, 2 Apr 2004, Raimar Falke wrote:
> 
> > On Thu, Apr 01, 2004 at 05:50:22AM -0800, nikodimka wrote:
> > > In regards of locking:
> > >
> > > a human player does not ever lock the civclient? right?
> >
> > No. Yes.
> >
> > > so not every kind of an external program does need to lock.
> >
> > I think a lot of external programs want to make multiple queries at
> > the common client data and want to not have it change from one query
> > to the next.
> >
> > > Anyways I have to think the locking through a little bit more.  For
> > > the first look it seems that a pair of "lock" and "unlock" commands
> > > would suffice.
> >
> > Yes.
> 
> I would like if someone explained me some more why this functionality is
> required. Making the code exponentially harder to debug for little gain is
> always a poor idea.

Locking?

The external program and the common client are two threads of
execution. The AI in the external program wants plan for a certain
fixed client state. During this planning multiple queries have to be
made to the common client. If now the common client isn't locked (you
may also call it frozen) the state can change at any point. Espically
between two queries.

An alternative would be that you make a snapshot of the complete
client state and the external program can query these
explicitly. Another one would be that the common client sends the
complete state to the external program in one big chunk. If both cases
you get a consistent client state.

Is this understandable?

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
  This message has been ROT-13 encrypted twice for extra security.