Allowing an activity to be launched multiple times in parallel

[Yoshiki Ohshima]

  Technical arguments aside, I thought that people feel the
stop/resume model of Activity important to Sugar.

  If so, I think the stop/resume model does invite the idea of
limiting to one instance of activity at a time.  Two parallel Write
sessions?  Then, we might as well consider to switch to the documents
and applications model.

-- Yoshiki

At Wed, 29 Oct 2008 20:23:48 -0400,
Benjamin M. Schwartz wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Deepak Saxena wrote:
> > On the XO, if we try to edit two documents concurrently on Write, we should
> > in my opinion only have on instance of write running which can switch quickly 
> > between document objects so the user percieves it as two separate instances.
> 
> I disagree strongly, for several reasons.
> 
> 1. Bitfrost requires that each instance be isolated from every other.
> Each instance only has access to the Journal items to which the user has
> explicitly granted it access.  Allowing multiple "apparent instances" to
> share data behind the scenes represents a privilege-combining attack.
> This is especially apparent if one instance has been launched with
> P_NETWORK but not P_CAMERA, and the other has been launched with the
> reverse privileges.
> 
> 2. A key feature of the Sugar Activity system is that writing Activities
> is _easy_.  The goal is to minimize the amount of work required to write
> an Activity.  Asking Activity authors to juggle multiple virtual instances
> creates tremendous complexity that is likely to produce bugs even when
> performed by experts (e.g. Browse), for no user-visible gain.
> 
> 3.  Two separate Activity instances already share a great deal, because
> the Linux kernel automatically uses CoW to keep only one copy of read-only
> memory needed by multiple processes.  Each Write instance uses no CPU when
> idle, so RAM is the only overhead.
> 
> As a matter of efficiency, there is certainly more we can do to decrease
> the memory overhead of running multiple instances.  People are working to
> improve the efficiency of our X icon caching system and python launcher.
> Even better would be to work on the python interpreter upstream to improve
> memory usage and reduce the dirtying of pages that could be shared.
> 
> - --Ben
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.9 (GNU/Linux)
> 
> iEYEARECAAYFAkkI/pQACgkQUJT6e6HFtqTCBgCfQg0RDoRC38U1mWmwzQSgfxJe
> i+AAn1nWN9EyvkYNJGSniZ5xfOxviyRd
> =Upkp
> -----END PGP SIGNATURE-----
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel