[freeciv-ai] Re: FreeCiv brief analysis
[Top] [All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
On Tue, Mar 30, 2004 at 04:00:37PM -0800, nikodimka wrote:
> --- Raimar Falke <i-freeciv-lists@xxxxxxxxxxxxx> wrote:
> > On Sun, Mar 28, 2004 at 09:55:47PM +0200, Guillermo Lopez Alejos wrote:
> > > Hi,
> > >
> > > As result of previous conversations and personal work, I've written a
> > > brief analysis of the ai client side. It's uploaded as "fc-analysis.tgz"
> > > in "ftp.freeciv.org".
> > >
> > > I would like you to read it carefully and tell me if something is wrong.
> > Which part (the external program which is attached to the puppeteer
> > interface or the common client) controls the puppeteer interface?
> > I.e. which part issues requests and which part responses?
> huh? I don't quite get the question. :(
> what do you mean saying "controls the interface"
> is it a terminology question?
> I would say that external program issues requests and client issues responses.
> The civclient openens the socket and decides when to close it.
Maybe this become clear if I show you the alternatives:
If the common client controls the interface
the common client would looks like this:
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:
lock common client
unlock common client
Now if the external program controls the client the roles are switched:
the common client has funtions like wait_for_packet() and
call wait_for_packet() in the common client
call process_packet() in the common client
So it boils down to where-is-the-mainloop. In the first scenario you
however have to think about locking.
Microsoft does have a year 2000 problem. I'm part of it. I'm running Linux.