Re: Issue GC-MESSAGES (Version 2)

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Tue, 03 Jan 89 12:38:44 EST
    From: Dan L. Pierson <pierson@mist.encore.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 agree in general.  I further think that the cleanest way to handle
    the problem is by having all such output be signalled.

This can't work for asynchronous, unsolicited typeout.  In a multiprocess
system, the cause of the condition leading to message output may not be
in a "user" process, so signalling in the originating process won't give
the user any control.  Also there may be multiple "user" processes and it
may not be obvious which one should receive the signal.  I shouldn't
have to tell this to someone from Encore, you must have faced all these
issues already!  Also a special form that disables unsolicited typeout
during the dynamic extent of its body could interact with the operating
system to disable or defer operating-system-generated typeout, but in
most operating systems it would be much more difficult to arrange for
the operating system to signal a Lisp condition when it wants to type
something out.

It's too bad it can't work, because it certainly would be cleaner.