[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]
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
Message not available
Message not available
|
|