[Dev] Multi User: Unique AMD with multiple Launchpads

Stéphane Desneux stephane.desneux at eurogiciel.fr
Mon Oct 21 08:28:55 GMT 2013

On 20/10/2013 05:56, Young Ik Cho wrote:
>     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.

Understood. Given that launchpads have already been split from AMD for 
some good reasons, we'll probably keep this model.

Concerning implementation details, if launchpads are separate processes, 
they should communicate with AMD to forward application 'events' to AMD 
(app started with given PID, app has been paused/stopped/killed etc.) so 
that AMD has always the correct vision of the running apps. Is it the 
right approach or am I missing something ?


Stéphane Desneux
Intel OTC - Vannes/FR

More information about the Dev mailing list