Complete.Org: Mailing Lists: Archives: freeciv-dev: May 2000:
[Freeciv-Dev] Re: setvbuf on stdout instead of using fflush
Home

[Freeciv-Dev] Re: setvbuf on stdout instead of using fflush

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: David Pfitzner <dwp@xxxxxxxxxxxxxx>
Cc: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: setvbuf on stdout instead of using fflush
From: "J. S. Bach" <gohmandj@xxxxxxxxxxx>
Date: Mon, 15 May 2000 16:18:15 -0500 (CDT)

On Mon, 15 May 2000, David Pfitzner wrote:

> Dan Gohman <gohmandj@xxxxxxxxxxx> wrote:
> 
> > I was looking through server/console.c and noticed that we're calling
> > fflush(stdout) after every output. We could accomplish the same thing by
> > turning off the buffering on stdout with setvbuf().
> 
> Yeah, we could, but is there a good reason why we should?
> I guess I'd like some more justification on why/whether
> this is a better approach... 
> 
> Eg, current code does not flush after _every_ line of output:
> mainly only when printing new prompt (eg, may occur after multiple
> lines of output).  It _may_ be that no buffering is preferable, 
> eg to make sure server gets timely output during long AI calcs etc,
> but OTOH current method does allow more potential control in when 
> and where we call con_flush().

I was looking through the console code to see how hard it would be to
add readline support[0], and thought I'd suggest this change. It seems
to me that we always want server messsages printed in a timely fashion,
(even if they are not currently) and this would allow us to not worry
about calling con_flush() anywhere.

[0] It appears that using readline in the server would require threads,
because otherwise we can't do anything while readline is waiting for
input. I'm not going to code this anytime soon, however.

-Dan




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