[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Inits opening stuff
- To: BUG-LISP at MIT-MC
- Subject: Inits opening stuff
- From: Richard L. Bryan <RLB at MIT-MC>
- Date: Wed, 27 Feb 80 15:54:00 GMT
- Cc: KMP at MIT-MC, BGS at MIT-AI, SJOBRG at MIT-AI, GSB at MIT-AI
- Original-date: 27 February 1980 10:54-EST
Date: 27 February 1980 08:23-EST
From: Brian G. Schunck <BGS at MIT-AI>
That's okay for init files, but what about general loads?
The problem yesterday was caused by a user doing
(LOAD '((DSK FOO) JUNK DATA))
several times until he got his small, trivial file of test
data setup correctly for his application. The LOAD never
did a CLOSE after reading in the file, and the computation
never got anywhere close to doing a GC, which would have
forced closing. ...
It seems clear that LOAD should have no use for its channel after it exits.
Error breaks, *RSET traps, etc., due to the LOAD should have INFILE available,
but that's all still within the context of the LOAD. Hence, the LOAD
internals should be "in" an UNWIND-PROTECT-like "construct" to make sure
LOAD's channel got closed. See KMP's IOTA.
If the luser insists on reLOADing from inside his error breaks, there's
little that can be done about it, but in the common (^G) case, this would
An alternative, but harder to implement, way would be for gc to treat a
"space" of I/O channels sort of the way it treats list space, etc., with
respect to gcmin/gcmax. If no ALLOC for IOCHAN space were done to increase
the number of chans avbl past an initial default (3 tty + 2 dsk?) then
GC-OVERFLOW would run on IOCHAN space ...