[Openmcl-devel] Playing with sockets

[Ron Garret]

On Feb 17, 2013, at 2:43 PM, Gary Byers wrote:

> 
> 
> 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 ...

Not necessarily... :-)

> 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 ...)

Now that I understand what's actually going on under the hood, I did some more experiments, including stopping CCL and restarting it.  I can now no longer reproduce the "weird" behavior that I was seeing earlier in the day.  So I suspect that what actually happened was that I somehow managed to kill the stream-flushing thread (I was using the IDE) earlier in my session without realizing it.

rg