[Dev] Multi User: Unique AMD with multiple Launchpads

Young Ik Cho youngik.cho at samsung.com
Sun Oct 20 03:56:10 GMT 2013


> Actually, launchpads are technically the parent processes of the launched
> apps and don't seem to have strong links with AMD (they are just slaves).
>
> The primary reason to have launchpads is performance (not security,
> control or anything else). So, from an architectural point of view, the
> launchpads could be ignored. You could just see them as extensions of AMD.


Very true. Launchpad and AMD got separated around Dec., 2012 due to Wrt
performance issue. Core and OSP still shares same launchpad now.



> IMO, having separate launchpads as actually is more a constraint than a
> benefit: handling the application lifecycle is complex because it's
> distributed: in a multiuser environment, we'd have a single launchpad which
> would be the parent of applications launched by different users... As a
> user would probably launch every kind of application (WRT/OSP/Core), we'll
> have multiple launchpads involved. Where's the intelligence ? IMO, a
> launchpad must be dumb and just has to run the things quickly. Its role is
> not to handle the whole lifecycle of applications launched by multiple
> users: it's AMD's role.
>
Just an idea to go further, Would it be possible to have the actual
> launchpads implemented as "plugins" of AMD (i.e running *inside* AMD). That
> would solve some problems:
> - AMD would be the parent process of every launched app: a single
> lifecycle could be controlled from AMD, whether the app is a WRT, OSP or
> core app.
> - if there's some communication between launchpads and AMD, being inside
> AMD makes probably thing easier (have a plugin API instead of a more or
> less complex communication interface)
>

AMD / launch actually provides plugin architecture w.r.t. package type
already. Currently only OSP provides this plugin
(platform/framework/native/env-config). However, the concept of separating
launchpad is process isolation.

Before separating AMD / launchpad, there was only "launchpad", which serves
the role of current AMD and preloading/preinitialization daemon. It
preloaded common shared libraries like X or efl and pre-initialized efl
common function.
However, wrt requires too many libraries which is not shared between core
or OSP and WebApp launch was still slow until that time.

After separating AMD and launchad, wrt_launchpad performs additional comon
initialization for web runtime and request to process pool. Currently due
to webkit2 restriction, each WebApp consists one UI process and one runtime
process and wrt_launchpad requests this initialization.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tizen.org/pipermail/dev/attachments/20131020/71c07784/attachment.html>


More information about the Dev mailing list