[squeak-dev] Review Request: DoItFirstAfterStartup.1.cs
David T. Lewis
lewis at mail.msen.com
Mon Jan 31 17:38:01 UTC 2022
Your changes in DoItFirstAfterStartup.1.cs look correct to me. I
tested on Linux and the --cwd command line option still works as
expected. So +1 for putting this in trunk. As an aside, I notice
that the existing FileDirectory class>>startUp method is mis-categorized,
we should move it to "system start up".
I am happy to do the merge if you like, but I'm not sure if I can do it today.
On Sun, Jan 30, 2022 at 09:02:22PM +0100, christoph.thiede at student.hpi.uni-potsdam.de wrote:
> Hi Marcel, Hi Dave,
> I don't see why you would expect this to work. The normal SourceFiles array already contains a writable pointer to the changes file, so of course it cannot be opened writable again. There can only be one writable pointer to a file at one time, at least on Windows. I am more surprised that this rule does not apply on Linux/macOS.
The restriction on opening multiple writeable pointers to a file
is a Windows design constraint that does not exist on other
platforms. Like many such things, it is either a bug or a feature
depending on your point of view ;-)
> On Windows, apparently we need to close the changes file before re-opening it. We can either implement this manually or apply my proposed patch instead, because even conceptually, I don't see a real sense in making #openSourceFiles itself idempotent. :-)
Your changes handle this is a good way. So yes, calling #closeSourcesFiles
first would probably take care of the issue on Windows, but I prefer
> Dave, you were probably unable to reproduce this in a debugger because once you have replaced the SourceFiles with a read-only pointer and old pointer has been GC'ed, the issue does not occur any longer. There is no limit for parallel read-only pointers on a file.
Ah, good. It makes perfect sense now :-)
More information about the Squeak-dev