[Openmcl-devel] Playing with sockets

Gary Byers gb at clozure.com
Sun Feb 17 22:43:14 UTC 2013



On Sun, 17 Feb 2013, Ron Garret wrote:

>
> On Feb 12, 2013, at 12:15 PM, Gary Byers wrote:
>
>> I think that it's
>> fairly common in other implementations to make streams be
>> "line-buffered" (so that something like FORCE-OUTPUT happens whenever
>> a #\newline is written to the stream.)
>
> Yep. and a lot of common software assumes this.  Notably (as I just found out the hard way), Quicklisp assumes this, so if you run (ql:update-client) it just sits there and does nothing until you press the return key, at which point it prompts you to press the return key.
>
> Two observations about this:
>
> 1.  I can't believe I'm the first person to notice this, and
>
> 2.  I would have sworn on a stack of bibles that CCL has exhibited line buffered behavior in the past.  I have specific recollections of running something like (dotimes (i 100) (print i) (sleep 1)) and having it do what I expected (i.e. print a number every second).
>
> Am I losing my mind?  Or did CCL used to be line buffered?
>

I'm afraid that it's the former ...

If it's any consolation, CCL may have contributed to this tragic situation in at least two ways:

1) The output side of a TWO-WAY-STREAM is flushed (via FORCE-OUTPUT) before input is read from
the input side; this is supposed to avoid scenarios like the one you describe, where something
waits for a response to a question that you haven't seen.  The initial value of *TERMINAL-IO*
is ordinarily a kind of TWO-WAY-STREAM, and the other standard stream variables are ordinarily
SYNONYM-STREAMs to *TERMINAL-IO*.

2) Some thread (the initial thread in command-line CCL, another dedicated thread in the Cocoa IDE)
spends most of its time asleep; it wakes up a few times a second to do "periodic tasks".  One of
these tasks involves trying to FORCE-OUTPUT on certain output streams, including the output stream
that's ordinarily the output side of *TERMINAL-IO*.  As of the last time I looked (probably several
years ago), SLIME used this mechanism or something similar.  (I often confuse "what's documented"
with "what's been discussed on this list or in some other public place", and am always surprised to
remember that things like "the autoflush mechanism" aren't documented.)

In any case ... CCL has never implemented line-buffering (or character-buffering) at the stream level.
(I think that I once made some classes of MCL streams character-buffered in the development version;
performance degraded so badly that that lasted about a day ...)


> rg
>
>



More information about the Openmcl-devel mailing list