[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[no subject]
- To: (BUG LISP) at MIT-AI
- To: HENRY at MIT-AI
- Subject:
- From: KEN@MIT-AI
- From: HIC at MIT-MC (Howard I. Cannon)
- Date: Wed, 18 May 78 03:09:08 GMT
- Date: Thu, 18 May 78 01:36:00 GMT
- Cc: (BUG LISP) at MIT-MC
- Original-date: 05/17/78 23:09:08 EDT
- Original-date: 17 MAY 1978 2136-EDT
From: HENRY@MIT-AI
Date: Tue, 17 May 78 19:59:31 GMT
Original-Date: 05/17/78 15:59:31 EDT
Subject: Re: lock for dumped Lisp systems
To: HIC at MIT-AI
There might be a problem with people
remembering to edit the lock file in the
manner you propose. Here's an alternative.
Keep a file with the names of files dumped
with the flush feature. It could also contain
the UNAMES of their maintainers. A simple
program run each time a new Lisp was dumped
could do the following. It could mail reminders
to maintainers to redump systems in the new Lisp.
After a while, a GC program could run around checking
(STATUS LISPVERSION) in each of the files, and
if all existing systems were updated, the copy
would be deleted.
------------
Your ideas regarding the handling of the LISP system are reasonable; but I want
to keep the mechanism down to a low level of complexity for all parties
involved. I don't want to have to have hairy hacks, and I want
to be able to find the cases of lossage fast. Therefore, I think the
single user-maintained file is the best scheme. BTW, even if a lISP does
go away it is a simple matter to restore it from backup tape, so there really
isn't that much lossage if the system maintainer forgets.....
--Howard