I've been trying to see if I can rid the image of the obscenity known as #readOnlyCopy with, unfortunately little luck so far. It's not so much a problem with excising #readOnlyCopy as such as the fairly pervasive assumption that files can be opened again and again and again. Unfortunately it is not always true that you can open a file already opened.
However, one place that really caught my eye whilst digging around was the rather odd seeming close-and-reopen process whenever changes are flushed to the changelog. This is despite the use of an explicit flush method... (see SystemDictionary>forceChangesToDisk or similar)
Does anyone know if this oddity is still required, or why it is used? Can it be dropped?
tim
...and while I'm whining about this part of the image, what is it with this abuse of FileStreams in ChangeRecord? The code absolutely assumes that each change record will have an instance of a _closed_ filestream that it can open and close when fetching the text of the associated method. In order to get such a filestream you rely implicitly upon having (ab)used readOnlyCopy. Yuck.
Using a file name to open and close would be a little less awful but since we know (I'm pretty sure) that change records are in the change file (or possibly one of several change files I suppose) why do we not just use it as is? It's already opened after all.
Sigh. I know there's precious little chance of getting this changed; look at the resistance to Flow. Grumble.
tim
On Wed, Jan 01, 2003 at 01:36:49PM -0800, Tim Rowledge wrote:
However, one place that really caught my eye whilst digging around was the rather odd seeming close-and-reopen process whenever changes are flushed to the changelog. This is despite the use of an explicit flush method... (see SystemDictionary>forceChangesToDisk or similar)
Does anyone know if this oddity is still required, or why it is used? Can it be dropped?
I suspect that there are any number of platforms on which it would be a bad idea to have the changes file open at the same time the VM decides to crash. I feel a bit safer overall having the changes file in a normally-closed condition.
However, now that you mention it... If you put a TimeProfile browser on something like this:
| fs | TimeProfileBrowser onBlock: [100 timesRepeat: [fs _ FileStream fileNamed: '/my/squeak/directory/squeak.changes'. fs close]]
You'll find that the real concern is in WeakRegistry>>remove:ifAbsent:
This actually turns out to be a very large performance impact on anything that closes lots of files. CommandShell takes a bit hit on this for instance.
I took a look at this a while ago, but was uncertain as to how to improve it.
Dave
"David T. Lewis" lewis@mail.msen.com is claimed by the authorities to have written:
I suspect that there are any number of platforms on which it would be a bad idea to have the changes file open at the same time the VM decides to crash. I feel a bit safer overall having the changes file in a normally-closed condition.
Oh, but it _isn't_ normally closed; the code flushes the filestream and then closes it and then opens it again!
tim
I think some VM's don't honor the flush, so the only way to flush (kinda) is to close the file. Mm the mac VM didn't flush until VM version v3.06
If all VM folks agree the file is actually flushed using some OS level flush routine, then I'd guess you could keep the file open?
On Wednesday, January 1, 2003, at 03:27 PM, Tim Rowledge wrote:
"David T. Lewis" lewis@mail.msen.com is claimed by the authorities to have written:
I suspect that there are any number of platforms on which it would be a bad idea to have the changes file open at the same time the VM decides to crash. I feel a bit safer overall having the changes file in a normally-closed condition.
Oh, but it _isn't_ normally closed; the code flushes the filestream and then closes it and then opens it again!
tim
-- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Strange OpCodes: RDRI: Rotate Disk Right Immediate
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
squeak-dev@lists.squeakfoundation.org