Well, we (the etoys minions) try to accommodate whatever the platform requires.
Our original thinking was to have just one Etoys process that serves multiple instances. There were issues on the Sugar side, like that Sugar insists on having a separate X window for each activity instance.
So for the time being we implemented a one-process-per-instance policy, first using a wrapper reusing the Python activity code, and currently using sugar-native-factory.c which forks off new Squeak/ Etoys instances.
So two instances do not share their memory at the moment which is inefficient. It could be more efficient if the "static" parts of the object memory could be shared, this is not supported yet - even if forking with copy-on write semantics the first full garbage collection would touch all pages (*).
OTOH, having separate processes simplifies activity handling quite a bit. For example, if two instances of Etoys would be shared on the mesh, they would have to be handled simultaneously, which would be hard if these were inside one Squeak process as only one Etoys project can be active at a time.
A "project" is the Etoys equivalent of an activity instance (predating Sugar but has pretty much the same keep/resume idea). A different issue is that we currently create multiple journal entries per instance, one per project. Only one project is ever active, but in one "session" multiple projects can be created.
So in short - we do have something that works now, we still would like to become more efficient, supporting multiple-instances-per- process might help with that, it gives more options to activity developers anyhow.
- Bert -
(*) We have a incremental mark-and-sweep GC, the mark bits are in each object header scattered trough memory, so they are written in each mark pass. And when compacting, objects move, and object references change, so a lot of memory is touched by that, too (although compacting happens less often than the incremental mark-and- sweep). The object memory and garbage collector was not designed for multi-threading.
On Jul 12, 2007, at 13:47 , Noah Kantrowitz wrote:
We (the security minions) had been working under the assumption that etoys would be operating in single-instance mode because of memory issues.
--Noah
Bert Freudenberg wrote:
Well, we can create several projects and switch between them, like for making a presentation. Until now this has been done inside Etoys. But my question was about what the desired Sugar model is, and we'll try to fit in.
See my mail to the olpc etoys list:
http://lists.laptop.org/pipermail/etoys/2007-July/000709.html
- Bert -
On Jul 12, 2007, at 16:03 , Tomeu Vizoso wrote:
Bert, how can a single eToys activity instance create several objects in the journal? Wouldn't be everything inside a single eToys project?
Thanks,
Tomeu
On Thu, 2007-07-12 at 09:25 -0400, Erik Blankinship wrote:
This is a good question; access to individual photographs & videos in the journal have this problem.
http://dev.laptop.org/ticket/1758
On 7/12/07, Bert Freudenberg bert@freudenbergs.de wrote: If I understand the Sugar philosophy correctly, we won't have multiple documents per activity. If we want to have multiple documents opened at the same time, these would be multiple instances of the same activity.
Is this the case? And if so, what would one activity instance have to do to create a new instance? - Bert -
etoys-dev@lists.squeakfoundation.org