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.

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.

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"....


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.
>
>
> 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
>
>
> Cheers,
> Max