[sugar] Multiple documents

[Bert Freudenberg]

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 at 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 -
>>>>
>>