On Tue, Jun 28, 2016 at 04:47:00PM -0500, Chris Muller wrote:
> 
> On Tue, Jun 28, 2016 at 5:04 AM, Max Leske <maxleske at gmail.com> wrote:
> > Hi,
> >
> > Opening the same image twice works fine as long as no writes to the .changes file occur. When both images write to the .changes file however it will be broken for both because the offsets for the changes are wrong. This can lead to lost data and predominantly to invalid method source code, which is a pain with Monticello.
> >
> > I suggest that we implement a kind of lock mechanism to ensure that only one image (the first one opened) can write to the .changes file.
> >

If the offsets are wrong in this scenario, it's a bug in the image. The
image is supposed to seek to the end of the changes file before writing
the next chunk. While this sounds horrible in theory, in practice it works
remarkably well, and I have been happily surprised at how reliable it
is after many years of using and abusing the feature. That is a very
good thing.

Adding a lock to prevent the scenario would be bad, because it would
surely break a number of other legitimate use cases.


> >
> > I???ve opened an issue for Pharo here: https://pharo.fogbugz.com/f/cases/18635/The-changes-file-should-be-bound-to-a-single-image
> >
> 
> 
> I have several applications which launch multiple copies of the same
> image for multicore processing.  The images do their work, commit it
> to database, then exit themselves without saving.  Its a great
> feature.

That is consistent with my experience. I remember expecting horrible
things to happen if I had two images sharing a changes file, but nothing
bad ever happened. It just works.

> 
> I know OSProcess, when combined with CommandShell, has a RemoteTask
> which allows efficient forking of the image (via Linux copy-on-write
> memory sharing) and so a solution like what happens in Windows is not
> really good.

My assumption with RemoteTask was that someone doing complex or long-running
jobs would more or less know what they were doing, and would have the good
sense to stop writing to the changes file from a bunch of forked images.
But in actual practice, I have never seen a problem related to this.
It just works.

> 
> Instead of putting a pop-up in front of the user, perhaps one way to
> solve the problem would be to, upon image save, simply goes through
> all the changes since the last save and re-flushes them to the
> .changes file.
> 
> That way, if someone does want to save the same image on top of
> themself, at least it would be whichever saved last "wins"....
> 

There must be a problem somewhere, otherwise Max would not be raising
the issue. So whatever combination of operating system and image is
having a problem, I would be inclined fix that.

Windows cannot be a problem, because the operating system will not
permit you to open the changes file twice. The Unix/Linux systems that
I have used all work fine.

Max, which operating system/VM/image are you using? Is this on a Mac?

Dave