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 ?
Regards, Stéphane -- Stéphane Desneux Intel OTC - Vannes/FR _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
