[Freeciv-Dev] Re: Threads!!??
[Top] [All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
Thats why I mentioned shared memory in the first place.. it seems that
the AI uses (or at least has the ability to use) a large amount of
the server resources. This is good for cheating and keeping down the
number of structures, but it is bad in terms of guaranteeing exclusive
memory access and other issues. I pondered these things last night, and
I came to the conclusion that handling locks and other thread safety in
the
server would be a nightmare beyond our wildest dreams.
So considering this, we are looking at the best solution being a client
AI, maybe even a single one that handles all the AI players. For the
average Redhat player that just pulls up freeciv off-line to play a
couple of turns while he is getting his tires changed, I think it would
have
to be small, and spawned automatically. (For the online server admin,
you could control all of this, of course).
Good discussion... this has helped me, I hope it has helped others.
Jordan
Reinier Post wrote:
>
> On Tue, Feb 06, 2001 at 09:17:39PM -0500, Jed Davis wrote:
>
> > In any case, having a shared memory space between the server and a
> > "client-side" AI maybe isn't very useful, because a client generally
> > doesn't need access to the server's data structures (and the protocol
> > tends to be designed with this in mind).
>
> Well, most of the protocol is concerned with transporting the contents
> of data structures shared by client and server, so I'm not really sure
> about this. The existing AI was put into the server because the
> author felt it had to have much *more* access to server data than
> a client for humans; he thought it would be essential to 'cheat'.
> I think on the cheating he proved himself wrong: the server AI
> doesn't seem to rely on it much.
>
> --
> Reinier
|
|