[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Issue GC-MESSAGES (Version 2)

    Date: Fri, 30 Dec 88 19:26 EST
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

    I still think that focussing on GC messages is wrong, and instead there
    should be a form that disables unsolicited typeout in general,
    regardless of its source.  Of course in some operating systems it might
    be impossible to disable some forms of unsolicited typeout, and in other
    operating systems unsolicited typeout might not exist (that is,
    asynchronous messages might always come out in a separate window).
    Thus this facility would just do the best effort appropriate for
    the particular implementation.

    I think there should be a stream argument, since there might be more
    than one possible place for unsolicited typeout.  In other words, 
    (WITHOUT-UNSOLICITED-OUTPUT (<stream>) <body>...) means that the output
    send by <body> to <stream> should appear as a unit, without other
    unsolicited output interspersed with it.

What if the typeout isn't going to a stream? Eg, some implementations might
cheat and do native non-stream-based I/O raw to the terminal during a GC to
avoid the risk of consing. I'm pretty sure I've seen some implementation
do this but I can't remember which.

Also, what if I do
 (WITHOUT-UNSOLICITED-OUTPUT (*TERMINAL-IO*) <body>)
? Does this affect unsolicited output to *STANDARD-OUTPUT*?

Also, what if I do
 (WITHOUT-UNSOLICITED-OUTPUT (*STANDARD-OUTPUT*) <body>)
? Does this affect unsolicited output to *TERMINAL-IO*?

Maybe we'd specify the stream to which unsolicited typeout is supposed to
go to help avoid problems like this. But then why would anyone bother to
use this macro on any other stream.

Without a way to test this property of a stream, no user-created stream
is going to ever respect this form anyway because unsolicited typeout
can't be distinguished from solicited typeout by the low-level printer
routines.

To my way of thinking, the root of this problem is that the system thinks
it is permissible to type on the virtual CL console. Personally, I think
this is a violation of the whole purpose of having stream-based I/O, which
is to keep the output of one program separate from the output of another.
Creating a stream-based abstraction to solve the problem of somebody 
violating the heart of the stream concept does not (without further
justification) seem to me the necessarily best way to proceed.

    I don't think your :VERBOSE T option to encourage unsolicited typeout
    is needed.