On Tue, 20 Jan 2004, Helmut Eller wrote:
Luke Gorrie luke@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@common-lisp.net http://common-lisp.net/mailman/listinfo/slime-devel