[Dev] Multi User: Unique AMD with multiple Launchpads

Stéphane Desneux stephane.desneux at eurogiciel.fr
Sat Oct 19 23:02:33 GMT 2013

Dominig ar Foll (Intel OTC) wrote:
>> Actually managing app lifecycle is the role of AMD. AMD is actually the
>> central daemon who maps process (pid) and app (appId).
> It seems that we are in sync, but we need to get the same wording.
> Yes, AMD is the central point and control the launch of an App for a given user.
> But the actual launch is done by one of the Launchpad(s) and so it's an easy
> point to keep track of the application which have been launched in order to
> control its live cycle.
> We could report all the live cycle control work to AMD, but that would require
> to pass back to AMD at least the pid once that the application has been launched.
> For me, its more a detail of implementation rather than an real architecture
> issue as I see the Launchpad(s) as an extension of AMD.


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.

So we should think about the architecture without being focused on launchpads.

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)

Stéphane Desneux
Intel OTC - Vannes/FR

More information about the Dev mailing list