Complete.Org: Mailing Lists: Archives: freeciv-ai: April 2004:
[freeciv-ai] Re: FreeCiv brief analysis

[freeciv-ai] Re: FreeCiv brief analysis

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Raimar Falke <i-freeciv-lists@xxxxxxxxxxxxx>
Cc: freeciv-ai@xxxxxxxxxxx
Subject: [freeciv-ai] Re: FreeCiv brief analysis
From: "Guillermo Lopez Alejos" <100030179@xxxxxxxxxxxxxxx>
Date: Wed, 7 Apr 2004 13:57:41 +0200 (CEST)


I've been busy these day so I couldn't write before.

> Maybe this become clear if I show you the alternatives:
> If the common client controls the interface 
>   the common client would looks like this:
>     forever:
>       wait for packet
>       process packet (this updates the internal state)
>       notify external program
>        (if the external program returns here or unlock the common
>        client would continue and wait for the next packet)
>   the external program may look like this:
>     notify_from_common_client_core():
>       lock common client
>       query client
>       calculate
>       issue commands
>       unlock common client

nikodimka said that this is the correct schema.

I understand the reasons for locking the client (I have followed this
thread) but I wonder if we can hide the locking of the client to the
external program.

We can define a turn-based-locking:
    1. puppeteer locks the client
    2. The external program issues its commands (some of them would
require to ask the server and change client's state; in this case the
client may be unlocked and locked again by puppeteer automatically)
    3. Finally puppeteer unlocks the client at the end of the turn of
the external program.

Note that the external program has to remain locked when waiting for
client response... hum... how can we release the external program from
doing this explicit? RPCs?

Guillermo López Alejos - N.I.A. 100030179
Universidad Carlos III de Madrid
Ingeniería Técnica en Informática de Gestión

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