Complete.Org: Mailing Lists: Archives: freeciv-dev: March 1999:
Re: [Freeciv-Dev] Forking of the client
Home

Re: [Freeciv-Dev] Forking of the client

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Trent Piepho <xyzzy@xxxxxxxxxxxxxxxx>
Cc: freeciv-dev@xxxxxxxxxxx
Subject: Re: [Freeciv-Dev] Forking of the client
From: Vasco Alexandre Da Silva Costa <vasc@xxxxxxxxxxxxxxxxxxxxx>
Date: Mon, 15 Mar 1999 09:39:57 +0000 (WET)

On Fri, 12 Mar 1999, Trent Piepho wrote:

> On Fri, 12 Mar 1999, David Pfitzner wrote:
> > Though I don't really see this impacting either way on
> > the idea of having the server fork a process to communicate
> > with each client.  But I don't know enough about 
> > sockets/processes etc to comment on the pros/cons of that idea.
> 
> Well, I know plenty about sockets/processes, and this isn't as easy as it
> looks.  First of all, when you fork a separate process it gets its own memory
> image that is a copy of the parent.  This means that if one server process
> changes its data structures, the other processes won't see this.

That's why you should use POSIX Threads instead of processes.

> You also have to insure that only one process tries to write to/read from the
> socket at once.  If once process is writing out a game map, and another tries
> to send a unit info packet, they can write on top of each other and
> scramble the data.  
> 
> So this means, you have to have some sort of locking mechanism if you want
> to have to processes share the same socket.

Yeah, those damned mutexes can be pretty annoying...

> It would be much easier to just have the server use non-blocking IO and select
> to write to the sockets.

Agreed, that's what i use most of the time anyway.  However multithreading
would be nice for those CPU eating AI characters.

---
Vasco Alexandre da Silva Costa, student @ Instituto Superior Tecnico,
Technical University of Lisbon - Software & Computer Engineering


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