[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Improved string writing
From: |
Kevin Ryde |
Subject: |
Re: [PATCH] Improved string writing |
Date: |
Fri, 22 Apr 2005 08:10:21 +1000 |
User-agent: |
Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (gnu/linux) |
address@hidden (Ludovic Courtès) writes:
>
> Actually, I hadn't considered using it because `stdout' is line-buffered
> by default, at least on GNU/Linux
Guile doesn't actually use stdio.
> (SUSv2 states that it shall be "fully-buffered" by default [1, 2]).
Fully buffered on a non-tty. On a tty you're right the tradition is
line buffered output.
> But it looks like Guile's file ports are unbuffered by default.
Ah yes, on a tty. (scm_init_standard_ports in init.c.)
> Maybe _this_ should be changed?
Alas I think that'd be an incompatible change, programs printing a
prompt or progress info probably depend on immediate output as the
default.
(In C stdio a prompt is handled by stdout automatically flushing when
stdin is read, but there's no such interlock in guile, I think.)
It'd be good to add a bit to the manual somewhere about this. I just
realized I struck something similar to what you're talking about only
the other day, running a guile subprocess from emacs. I fiddled about
with strings to ensure decent size chunks got written for performance.
(Emacs uses a pseudo-tty to talk to subprocesses, rather than a pipe.)
> It looks better to call `scm_lfwrite ()' once than `scm_putc ()' for
> each character, especially since `scm_putc ()' calls `scm_lfwrite ()'
Yes, but I would limit that to what can be done easily locally, like
two adjacent putcs turned into one write. I'd leave general sort of
buffering to the port or an application.
> `scm_lfwrite ()' does this so Guile code doesn't have to care about it.
Yep, format.scm started as portable to systems without builtin output
column tracking, I think. I thought of changing to use the port as a
simplification, I guess it's also an optimization.