[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue GC-MESSAGES (Version 1)
- To: CL-Cleanup@SAIL.STANFORD.EDU
- Subject: Issue GC-MESSAGES (Version 1)
- From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Thu, 23 Apr 87 17:46 EDT
- Cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Edit history: 23-Apr-87, Version 1 by Pitman
Status: For Internal Discussion
Although there is no standard interface to the garbage collector,
it is common for there to be a garbage collector in nearly every system.
In many systems, these do unsolicited typeout which obstructs program
typeout in unpredictable ways.
Make a variable called *GC-MESSAGES* which controls GC message typeout.
Possible values of this stream include:
T Standard notifications (typically to *TERMINAL-IO*).
NIL No notifications.
Since not all implementations could allow an arbitrary user-supplied
stream for use as a value of *GC-MESSAGES* (because streams might cons
and consing might be illegal at the time of the message), this cannot
be offered as an option. However, this would be a reasonable
implementation-dependent extension in some systems, so we should offer
it as an option.
In multi-processed, shared-address space implementations, if the GC is
going to type a message on a stream that belongs to some other process
(or otherwise ``notify'' the process, to use Lisp Machine terminology),
the value of *GC-MESSAGES* in the process being notified should be used
rather than the value in the current process so that this variable can
be usefully bound by user programs.
Permit that as an act of desperation, shortly before running completely
out of space when *GC-MESSAGES* is NIL, the GC may notify the user
that he is about to lose (in spite of the fact that he has seemingly
asked to lose). This permission is important so that people don't feel
afraid to bind *GC-MESSAGES* to NIL to suppress frequent messages
only for fear that they might not get critical last minute information
that says it's time to do drastic cleanup action.
Application programs which do display (especially display which conses)
need a way of deferring GC warnings that might ruin the display.
This functionality is provided in some form or another by a number of
Zetalisp currently offers SI:GC-REPORT-STREAM which can be set to T, NIL,
or a stream. It provides useful flexibility and is used by quite a number
Other systems provide ways of enabling or disabling the messages, or of
customizing the message which is typed out.
The set of places in which the GC does typeout is probably very
restricted, so finding them and changing them to be appropriately
conditionalized is probably not a lot of work.
This would allow the user some portable control over a common feature which
cannot currently be controlled in a portable way.
This is an upward compatible change.
No significant impact.
MACSYMA needs this (so it can bind it to NIL). Its display often does
consing. In some implementations this can cause a GC, which can in turn
spoil the carefully crafted display.