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