[Freeciv-Dev] Re: Threads!!??

[Jordan Crouse <jordanc@xxxxxxxxxxx>]

> The current AI in the server will stay at least till the client side
> AI is equal or better compared to the server AI. The term "better"
> should cover game play strength, resource usage and use-ability. So
> you don't need to worry that the server AI will get obsolete in the
> next time.

I expect the AI will be constantly evolving on both sides for many moons
to come. 

> I haven't worked with threads in C. However I have heared it isn't
> easy. Do you have any experience with threads in C. Threads are a nice
> concept but so are processes.

Actually, threads are processes that haven't been completely spawned
off.  Threads and processes both maintain their own
stack and PC information (and are thus handled individually by the
scheduler), but where processes are given their own memory space, 
threads share the same memory as the calling process.  This had its
advantages and disadvantages.   The advantage is that you can have
multiple execution points, but only one memory footprint.  That is
useful for servers and GUI applications that are processor intensive 
(browsers come to mind -- the HTTP handling is on a separate process so
the GUI doesn't lock up while you're accessing a slow site).

Of course, the disadvantage is that it is very easy to enter race
conditions if you are not careful, which results in zombie processes and
other annoying things.

So keeping these in mind, we could use the pthread library (which is
pretty much the universal standard for linux threading), and 
it wouldn't be too bad.  I am comfortable with threads, so I might be
biased, but I would vote that threads would be a better way to go,
as long as we are keeping the UI in the server.  We could even have a
master thread that handled all AI players in one thread, which might
be a better way to reduce the stress on the system.

If we are moving it out to the clients, however, threads would be
redundant.  

> Extra silicon cycles or extra brain cycles?

I can offer both, though I think most people would prefer a faster
machine than mine.  

Jordan

 
Raimar Falke wrote:
> 
> On Tue, Feb 06, 2001 at 04:54:18PM -0700, Jordan Crouse wrote:
> > So my read is that this is best left to a client side AI system, spawned
> > and maintained locally.  My focus has been working on diplomacy primarly
> > for offline play.  Client side is a good solution, but I worry about the
> > scaling and complexity that it gives the standard joe who just wants to
> > fire up a game and play offline.  I normally set aifill to 4 or 6.  Do
> 
> The current AI in the server will stay at least till the client side
> AI is equal or better compared to the server AI. The term "better"
> should cover game play strength, resource usage and use-ability. So
> you don't need to worry that the server AI will get obsolete in the
> next time.
> 
> > we spawn 6 identical processes?  Is this better or worse than spawning 6
> > identical threads, or waiting for the server to crunch options for 6
> 
> I haven't worked with threads in C. However I have heared it isn't
> easy. Do you have any experience with threads in C. Threads are a nice
> concept but so are processes.
> 
> > different AI players?  I suppose that is a question for the
> > philosophers.
> >
> > None the less, event processing is an idea who's time has come if server
> > side diplomacy is ever going to get off the ground.  But I yield myself
> > to the voice of the people, and I will back off of my server side work,
> > and offer my services if any of the client side AI folks need someone to
> > throw in a couple of extra cycles.
> 
> Extra silicon cycles or extra brain cycles?
> 
>         Raimar
> 
> --
>  email: rf13@xxxxxxxxxxxxxxxxx
>  "Just because you put a flag on the moon doesn't make it yours, it just
>   puts a hole in the moon."