On 19/10/2007, David T. Lewis <lewis at mail.msen.com> wrote:
> On Thu, Oct 18, 2007 at 06:36:00PM +0300, Igor Stasenko wrote:
> >
> > Then i think, it would be good to make some steps towards supporting
> > multiple images by single executable:
> > - make single executable capable of running a number of images in
> > separate native threads.
> > This will save memory resources and also could help in making
> > inter-image messaging not so costly.
>
> What memory and resources do you think that you will save? Squeak
> already does almost exactly what you describe when you run it on a
> unix/linux/OSX platform. Putting the interpreters into separate
> threads (as opposed to unix processes) would at best save a trivial
> amount of memory, and would add a lot of complexity.

I can't see how OS process handling can be less complex than threading.
Also, unix is the best example among OS-es, which tries to do things
nicely. But on windows, for instance, it not shares a DLL's instances
between processes resulting to have a copy of same DLL for different
processes.

>
> I don't see any savings for inter-image messaging either, but
> maybe I'm missing something there.
>

Well, for spoon 'imprinting' it requires that you copy object's
behaviors between images. By having an images kept in same process,
you can just put them as external references.
For same reasons, inter-image message sends can be done without
serializing objects, because all objects of all images are accessible
at any time.
Also, the things above don't restricts you to have inter-image
processing only for images kept in same process. But for me it's
obvious, that inter-image processing between images which are in same
process address space can be greatly simplified.

> Dave
>

-- 
Best regards,
Igor Stasenko AKA sig.