Re: Issue GC-MESSAGES (Version 2)

[Dan L. Pierson <pierson@mist.encore.com>]

    Date: Tue, 3 Jan 89 12:50 EST
    From: 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.

Maybe I did tack this on to the wrong message.  GC-MESSAGES may well
have to be a special case, both because they're almost the only truly
asyncronous events that don't invoke a debugger, and because they have
special consing problems as Kent reminded us.  I think that all (or
almost all) other messages can still be treated in one uniform way.

                                                            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.

Well, the condition system spec doesn't talk about how handlers are or
aren't inherited across processes.  Since handlers are dynamically
scoped, it might be assumed that a process "inherits" all the handers
in existence when it is created.  While this is probably not true in
most (if not all) existing Lisp multiprocessing systems, it's absence
does make it much harder to bullet proof a delivered application.  

In addition, if handlers are inherited, it would be nice for any lisp
system to allow a user to define handlers that will be inherited by
all processes; I realize that this may not be possible for system
processes in a Lisp Machine.

                           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!

We have, but not in a Lisp context!  In general you can either have a
special signal handling process or let each process do it's best.  It
depends on what the signal and application are trying to do.  A single
signal handing process doesn't scale well, so I wouldn't want to use
it for something like divide by zero execptions (if my code was
prepared to handle those efficiently and I could get them delivered to
the originating process(or)), but that probably doesn't matter for
user interfaces.  On the other hand, scaling doesn't really matter
unless you have several multiple processors.  A Mach approach is to
have one thread with receive rights to a port that gets all errors.

While I'm very concerned about language changes that might make a
parallel lisp harder to create or define, I've been less worried about
user interface issues like this.  All of your hard objections apply
just as much to any error handling (or even invoking the debugger) as
they do to printing a message.  We've adopted a condition system that
doesn't deal with any of these issues because the language standard
doesn't deal with multitasking (e.g. stack groups) at all, let alone
true parallel processing.  If the condition system is going to be
useful to users (and customers), multitasking implementations are
going to have to find answers to many of these problems.  It won't be
easy, but that does that mean that we'd be better off without a
condition system?

                     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.
    
True, but the stock hardware operating systems I've worked with don't
tend to type things out.  They just signal errors, return a bad status
code, or abort your program.  Of course, linked-in foreign language
code may do such a thing, but that's only a problem for
implementations that use such code themselves.  Any typeout proposal
that we come up with isn't going to control what the user can do to
himself.

    It's too bad it can't work, because it certainly would be cleaner.
    
It can't work for GC-MESSAGES, but does that mean it can't work for
the loader, compiler, etc?  I'm not convinced yet.