[slime-devel] Re: autoflush of streams

Gary Byers gb at clozure.com
Tue Jan 20 20:18:05 UTC 2004



On Tue, 20 Jan 2004, Helmut Eller wrote:

> Luke Gorrie <luke at bluetail.com> writes:
>
> It would probably be good if *standard-output* where line buffered.
> Line buffering isn't difficult to implement for the gray streams, just
> a bit inefficient.  Things are more complicated for the dedicated
> output stream case.  The simplest solution for CMUCL/SBCL would be a
> 'buffering' argument to accept-connection, where buffering is either
> :full, :line, or :none.  Don't now how to do the equivalent in
> OpenMCL, though.  Any ideas?
>
> We could implement the line buffering for the dedicated output stream
> with gray stream wrappers, but that's not very elegant.

All (instantiable) streams in OpenMCL are Gray streams, which means
that they follow a certain protocol for how things like READ-CHAR and
LISTEN and FORCE-OUTPUT are implemented.  The Gray streams protocol
says nothing about how streams are buffered; presumably, interesting
subclasses of FUNDAMENTAL-STREAM do buffering in appropriate ways.

Following the stdio (full/line/none) buffering model for interactive
streams never struck me as being particularly appropriate: it's less
important that output be flushed on every line/character/whatever than
that the user see it in a timely manner.  OpenMCL arranges to
periodically try to FORCE-OUTPUT on certain designated streams; this
seems to do a good job of maintaining the illusion that they're
unbuffered without requiring the buffering code to follow the stdio
(or similar) model.

Unfortunately, the mechanism by which streams are designated for
this periodic buffer-flushing is ad hoc: it's currently tied in
to the code that creates OpenMCL's own listener threads and
establishes *TERMINAL-IO* streams for them.  It should probably
be an option to stream-creation primitives (including socket-
creation primitives), and I imagine that there's already an
abstraction layer around those primitives in SWANK/SLIME.

>
> Helmut.
>
> _______________________________________________
> slime-devel site list
> slime-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/slime-devel
>
>




More information about the slime-devel mailing list