On 19/10/2007, David T. Lewis lewis@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