Complete.Org: Mailing Lists: Archives: freeciv-dev: August 2001:
[Freeciv-Dev] Re: [PATCH] Corecleanup_06 has been put in incoming
Home

[Freeciv-Dev] Re: [PATCH] Corecleanup_06 has been put in incoming

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: "Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>
Cc: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: [PATCH] Corecleanup_06 has been put in incoming
From: Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>
Date: Mon, 20 Aug 2001 08:44:11 +0200
Reply-to: rf13@xxxxxxxxxxxxxxxxxxxxxx

On Sun, Aug 19, 2001 at 06:34:49PM -0400, Ross W. Wetmore wrote:
> At 09:35 PM 01/08/19 +0200, Raimar Falke wrote:
> >On Sun, Aug 19, 2001 at 01:54:20PM -0400, Ross W. Wetmore wrote:
> [...]
> >> Subject:  [Patch4cvs] Autogame patch
> >> Date:     Aug 18, 2001
> >> Author:   Ross Wetmore
> >> Status:   Tested
> >> State:    Submitted to CVS
> >> 
> >> Description
> >>   This adds changes to allow autogames to run at full speed, make a final
> >> auto savegame and exits when done. The GAME_MIN_TIMEOUT value is adjusted
> >> in DEBUG mode to allow setting a value of -1 to trigger autogame mode.
> >> 
> >> Dependencies
> >>   none
> >> 
> >> Files Changed:
> >> corecleanup_06autogame: freeciv/common/game.h
> >> corecleanup_06autogame: freeciv/server/sernet.c
> >> corecleanup_06autogame: freeciv/server/srv_main.c
> >
> >I noticed that in an all-ai game the civserver process doesn't take
> >the full cpu like I would expect it. I have never took the time to
> >track it down. It looks like your patch address this problem. It this
> >correct? If this is the case the select() call is the problem? 
> 
> Yes, there is a 1 second timeout on select calls, and at least two such
> places where sniff_packets does this. So, you always end up wating until
> the next
> second rollover. The patch recognizes autogame mode, and returns what it
> would if it timed out in select in the code block immediately after rather 
> than going through the select code to do this. This is only triggered in
> !GAME_PRE_STATE, so you pass through to the normal select code and console 
> input until you actually say "go" get into running the game. 
> 
> Since you are not sleeping in select, the system also assigns any used
> CPU on its clock tick updates to the process, rather than the idle process, 
> so the user times are sensible, and more closely match the real times.

Good.

> Of, course this now makes the server a rather effective client killer,
> as there are no gating controls on its output and it never listens for 
> input :-).
> 
> >If so
> >is it possible to add something like
> >
> > int used_connections=0;
> >
> >    for(i=0; i<MAX_NUM_CONNECTIONS; i++) {
> >      if(connections[i].used) {
> >         used_connections++;
> >      }
> >    }
> >   if(!used_connections)
> >       return 0;
> >
> >instead of your code? Would this to the trick?
> 
> It might, but I think you want the same GAME_*_STATE checks. I'm also
> more comfortable with someone explicitly setting timeout to -1 as an 
> indicator that they want just this behaviour, rather than intuiting it 
> from the game environment (and possibly getting it wrong).

Correct. If a user starts a normal game (one user and some ais) and
the user gets disconnected the server will go to fast mode and the
client will never have a chance to reconnect.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx


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