File closing annoyances

David T. Lewis lewis at
Wed Jan 1 23:21:44 UTC 2003

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

I took a look at this a while ago, but was uncertain as to how to
improve it.


More information about the Squeak-dev mailing list