On 2024-03-31, at 9:04 AM, lewis@mail.msen.com wrote: I'm also interested in the idea of doing the saving work in a separate forkSqueak OSProcess to let it run at low priority, and with little or no performance impact on multi-core platforms.
This is an idea I like for quite a lot of long-running operations, and this particular case seems ideal.
I can't remember any detail of how the squeaksource save is done, but forking the entire image usually takes close to zero time and then the forked image can take its time to complete the job. The possible complication I can imagine (and that may not apply, see above memory issue) would be if multiple save requests are made during the time a forked save is running. I *think* there can Only Be One data.obj and if we get multiple concurrent requests to save it we could probably just kill any running fork and let a new one replace whatever had been already written?
Oh, and this reminds me that the ARM64 VM still explodes if you try to do the fork; IIRC we concluded it was sometihng to do with executable permission pages and resetting the phase of the chocolate clock, something like that.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim The severity of the itch is proportional to the reach.