Number: 1026
Date: 8-May-84 11':43':47
Submitter: Sannella.PA
Source: Masinter.PA
Subject: (GETSTREAM <string>) should not cause permanent storage allocation
Lisp Version:
Description: '
Date': 5 MAY 84 22':10 PDT'
From': MASINTER.PA'
Subject': fix (READ string) not to cause permanent storage allocation'
To': LispSupport'
cc': Kaplan'
'
The change introduced way long ago where (READ string) caused some permanent data to be allocated was a bad idea.'
'
I think that (GETSTREAM string) can be done in a way that the ''stream'' is in fact one where the get function is GNCHCODE or whatever it is called these days, and if the stream gets thrown away, no problem.'
'
This would solve problems like this one':'
'
7 - *******************************************'
Return-Path': SHULMAN@RUTGERS.ARPA'
Received': from RUTGERS.ARPA by Xerox.ARPA ; 02 MAY 84 06':20':08 PDT'
Date': 2 May 84 09':20':16 EDT'
From': Jeffrey Shulman <SHULMAN@RUTGERS.ARPA>'
Subject': Re': Tutor'
To': Raim.pasa'
cc': Masinter.PA, SHULMAN@RUTGERS.ARPA'
In-Reply-To': Message from "Raim.pasa@XEROX.ARPA" of 1 May 84 23':38':00 EDT'
'
'
There is a function called something like'
CONVERT.STRING.TO.LIST (I don''t have the sources in front of me.) The'
purpose of this function is to take a string and convert it into a'
list of atoms. The reason I just didn''t do (READ string) was that'
that left the string taking up lots of space in some hash table even'
when I was done with it. My conversion function cleaned up after'
itself (this is *extremely* important since *ALL* the output text goes'
through this function at compile time.)'
If you would like to fix it I believe the new functions is'
called GETSTRINGSTREAM (at worst I think GETSTREAM will work.) You'
may also need to find out again where the string hash table is kept'
(Larry - It really would be nice if the system itself cleared this'
table after a (READ string) was finished.)'
If you don''t want to fix it I''ll fix it by Saturday (or you'
could just redefine this function AS (READ string) if you only need'
to recompile one function.) '
In the future I will not be giving you dump files since they'
are a pain for me to make. If you would like to provide a more secure'
place for the source files please let me know.'
'
Jeff'
-----'
'
From': KAPLAN.pa'
Date': 6-May-84 14':12':57 PDT'
Subject': Re': fix (READ string) not to cause permanent storage allocation'
In-reply-to': MASINTER''s message of 5 MAY 84 22':10 PDT'
To': MASINTER'
cc': LispSupport, Kaplan'
'
I''m confused. I don''t understand Larry''s suggestion--and I don''t understand Shulman''s discussion of a hasharray. The string hasharray was removed from the system 6 months to a year ago. Streams on strings created by GETSTREAM of a string show up on OPENP), and are closed and flushed by CLOSEALL.'
'
(The hash array idea would have been superior, except that there are no current plans to make hash keys collectable, altho several suggestions have been made).'
'
-----'
'
From': MASINTER.pa'
Date': 6-May-84 15':02':49 PDT'
Subject': Re': fix (READ string) not to cause permanent storage allocation'
In-reply-to': KAPLAN''s message of 6-May-84 14':12':57 PDT'
To': KAPLAN'
cc': MASINTER, LispSupport'
'
I think that the string streams which are created by GETSTREAM should not show up on OPENP. I think that if you do a '
(GETSTREAM string) and then do some BINs that the string should just get gobbled up.'
'
("Make it work like it does in Interlisp-10" I think is what the AR should read, no?)'
'
-----'
'
Date': 6 May 84 21':57 PDT'
From': JonL.pa'
Subject': Re': fix (READ string) not to cause permanent storage allocation'
In-reply-to': MASINTER.PA''s message of 5 MAY 84 22':10 PDT'
To': MASINTER.PA'
cc': LispSupport.PA, Kaplan.PA, Raim.pasa, Shulman@Rutgers'
'
The function Shulman wants is OPENSTRINGSTREAM -- this should have gone into some release message before now, but I''ll bet it isn''t there.'
'
-----'
'
Return-Path': SHULMAN@RUTGERS.ARPA'
Received': from RUTGERS.ARPA by Xerox.ARPA ; 07 MAY 84 05':42':12 PDT'
Date': 7 May 84 08':42':57 EDT'
From': Jeffrey Shulman <SHULMAN@RUTGERS.ARPA>'
Subject': Re': fix (READ string) not to cause permanent storage allocation'
To': JonL.pa, MASINTER.PA'
cc': LispSupport.PA, Kaplan.PA, Raim.pasa'
In-Reply-To': Message from "JonL.pa@XEROX.ARPA" of 7 May 84 00':57':00 EDT'
'
'
I did find OPENSTRINGSTREAM in Fugue.6 and will put it in my'
code. I am *assuming* that stream (and string) will "go away" (i.e. be'
GC''ed) as soon as nothing points to this stream any more??? (not like'
Fugue.4 where this string and associated stream was cached in a hash'
table.)'
'
Jeff'
-------'
'
From': kaplan.pa'
Date': 7-May-84 8':07':41 PDT'
Subject': Re': fix (READ string) not to cause permanent storage allocation'
In-reply-to': SHULMAN@RUTGERS.ARPA''s message of 7 May 84 08':42':57 EDT'
To': Jeffrey Shulman <SHULMAN@RUTGERS.ARPA>'
cc': JonL, MASINTER, LispSupport, Kaplan, Raim.pasa'
'
This is true. It disappears when you drop all pointers (unlike the one that is created implicitly when you do (READ string); that one is saved in \OPENFILES so that its state is available for future READ, RATOM, etc. That one disappears if you CLOSEF it explicitly, or CLOSEALL.'
'
--Ron'
'
-----'
'
Date': 7 May 84 15':24 PDT'
From': JonL.pa'
Subject': Re': fix (READ string) not to cause permanent storage allocation'
In-reply-to': kaplan.pa''s message of 7-May-84 8':07':41 PDT'
To': kaplan.pa'
cc': SHULMAN@RUTGERS, JonL.pa, MASINTER.pa, LispSupport.pa, Raim.pasa'
'
A point to remember': after all the discussion about the potential "FULLNAME invariant", we still haven''t got a version of OPENSTRINGSTREAM which remembers what string the stream came from. Thus the string can easily go away "instantly" at the first GC after the call to OPENSTRINGSTREAM returns.'
'
The win, as far as Jeff is concerned, is that he need not succumb to the "awful kludge".'
'
-- JonL --'
'
-----'
'
Date': 7 May 84 15':32':18 PDT (Monday)'
From': Masinter.PA'
Subject': Re': fix (READ string) not to cause permanent storage allocation'
In-reply-to': JonL''s message of 7 May 84 15':24 PDT'
To': JonL'
cc': kaplan, SHULMAN@RUTGERS, MASINTER, LispSupport, Raim.pasa'
'
well, the string can go away, but the characters won''t. That sounds like a good reason not to have a back pointer from the stream to the string, no?'
'
-----'
'
Date': 7 May 84 15':37':51 PDT (Monday)'
From': Masinter.PA'
Subject': Re': fix (READ string) not to cause permanent storage allocation'
In-reply-to': KAPLAN''s message of 6-May-84 14':12':57 PDT'
To': KAPLAN'
cc': MASINTER, LispSupport'
'
I don''t think that streams on strings created by GETSTREAM should show up on (OPENP). I think they ought to be collected ASAP. The only way of doing that, of course, is to save all of the state in in the string pointer, by making it so whenever you BIN from a string-stream, it goes back and smashes the string.'
'
The streams opened with OPENSTREAMSTRING of course can work differently.'
'
-----'
'
Date': 7 May 84 16':00 PDT'
From': JonL.pa'
Subject': OPENSTRINGSTREAM and the (READ string) problem'
In-reply-to': Masinter.PA''s message of 7 May 84 15':32':18 PDT (Monday)'
To': Masinter.PA'
cc': JonL.PA, kaplan.PA, SHULMAN@RUTGERS, LispSupport.PA, Raim.pasa'
'
Certainly not -- knowing where the stringstream originated is quite useful, and not saving a pointer to the string header would at most cause early (premature, I''d say) GC of the two cells of the header. There''s no problem of circular references here, like there used to be in the window/displaystream complex.'
'
-----'
'
Date': 8 May 84 10':12 PDT'
From': Kaplan.pa'
Subject': Re': fix (READ string) not to cause permanent storage allocation'
In-reply-to': Masinter.PA''s message of 7 May 84 15':37':51 PDT (Monday)'
To': Masinter.PA'
cc': LispSupport.PA'
'
I understand your suggestion, and I agree with it. There can be a global resource which is the stream that getstream returns when given a string as argument. The BIN function will be based on GNCCODE, which updates the string pointer. Unlike streams opened by OPENSTRINGSTREAM, this string stream will be INPUT only.'
'
I suppose an AR ought to be submitted to this effect.'
'
--Ron'
Workaround:
Test Case:
Edit-By: masinter.PA
Edit-Date: 16-Aug-84 14':05':49
Attn:
Assigned To: Masinter
In/By:
Disposition: From': Masinter'
Date': 15 Aug 84'
Subject': AR#1026, (GETSTREAM <string>) should not cause permanent storage allocation, fixed'
To': Kaplan, shulman@rutgers, raim.pasa, jonl, LispSUpport'
'
The consequence of this is that if you do READs from strings, it will work like it usedta in Interlisp-10 -- it may generate some local storage (it will create a STREAM) but the stream will get GC''d, and there will be no *permanant* storage allocation. '
'
It *will* actually cannibalize the string -- each BIN turns into a GNCHARCODE. I had to put in some logic so that it could back up one character (which READMACROs require you to be able to do), but other than that , it is a simple straightforward implementation.
System: Operating System
Subsystem: Generic File Operations
Machine:
Disk:
Microcode Version:
Memory Size:
File Server:
Server Software Version:
Difficulty: Easy
Frequency: Everytime
Impact: Moderate
Priority: Perhaps
Status: Fixed
Problem Type: Performance
Source Files: