In my app I need update pharo image with some resources (new package, icons,
configs...) remotelly.
After updating I need save image session. For that app show user some
special screen, save image and return to ussual app state.
My app has process that do system changes when needed and "commit" it
> What is correct way to save image for my purpose?
Don't fork.
Lukas
--
Lukas Renggli
www.lukas-renggli.ch
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
But How I can do that without fork? I track changes in another process and
when I do update I save image in this process.
How I can initiate image saving from ui process?
2010/7/23 Lukas Renggli
> > What is correct way to save image for my purpose?
>
> Don't fork.
>
> Lukas
>
> --
> Lukas Renggl
> But How I can do that without fork? I track changes in another process and
> when I do update I save image in this process.
> How I can initiate image saving from ui process?
I don't understand what you are saying.
The thing is that using #fork to save the image has no effect (other
than wrecki
Sorry for not correct thread title.
I dont need save image in background while all system continue work.
I just want save image from my smalltalk process.
And when I do this I sometimes cant restart image (it crash due to some
world cycle activity and freetype plugin failure).
But when I save ima
On Fri, Jul 23, 2010 at 09:49:46AM +0200, Lukas Renggli wrote:
> > But How I can do that without fork? I track changes in another process and
> > when I do update I save image in this process.
> > How I can initiate image saving from ui process?
>
> I don't understand what you are saying.
>
> The
David, is what is said about memory management really true? I thought
that saving the image triggered a garbage collect what forces to copy
the whole memory anyway.
Lukas
On 23 July 2010 14:00, David T. Lewis wrote:
> On Fri, Jul 23, 2010 at 09:49:46AM +0200, Lukas Renggli wrote:
>> > But How I
Yes, it really is true. That said, I would expect the practical impact
to vary depending on how busy the main image is.
If you are running a Squeak/Pharo image that is not busy, such as your
own personal desktop image or a Seaside image that is not currently
receiving requests, then the additional
Cool, thanks for the update.
On Friday, July 23, 2010, David T. Lewis wrote:
> Yes, it really is true. That said, I would expect the practical impact
> to vary depending on how busy the main image is.
>
> If you are running a Squeak/Pharo image that is not busy, such as your
> own personal deskto
Here's my understanding of how it works. Garbage collection is completed
before the Unix fork system call is made. At the moment of the fork, the
original server VM process and the new image saving VM process share the
exact same pages in the Unix OS - due to "Unix copy-on-write memory
manageme
On 23.07.2010, at 17:11, David T. Lewis wrote:
> Yes, it really is true. That said, I would expect the practical impact
> to vary depending on how busy the main image is.
>
> If you are running a Squeak/Pharo image that is not busy, such as your
> own personal desktop image or a Seaside image th
On 2010-07-23, at 9:03 AM, Yanni Chiu wrote:
> Here's my understanding of how it works. Garbage collection is completed
> before the Unix fork system call is made. At the moment of the fork, the
> original server VM process and the new image saving VM process share the
> exact same pages in th
12 matches
Mail list logo
