Results 1 to 9 of 9

Thread: multi-process FE concept (for NG3)

  1. #1
    licensed to kill - FKA kev000
    Auto Apps:loading...
    tripzero's Avatar
    Join Date
    Aug 2006
    Location
    16.40618, 120.61106
    Posts
    2,494

    multi-process FE concept (for NG3)

    I would normally post this in just the openice/linuxice forum, but I thought it may be useful to share the idea and possibly get input from others on the concept.

    The concept: A multi-process frontend for in-vehicle-infotainment systems.

    For nGhost2, we developed an extensive IPC (Inter-Process-Communication) interface and toolkit library with the hopes that other apps would be developed that used the toolkit to maintain look/feel yet remained a separate process. Communication between apps still worked because of the IPC engine.

    In theory, this allowed the Linux window-manager (WM) to do it's job instead of nGhost taking over that role (traditionally, 3rd party apps are embedded into the FE and the FE assumes WM functions). In which case, the user could use a window manger like compiz and add eye-candy and some usefulness (via the Scale and Expose Plugins). An example of some eyecandy effects via the window manager can be found here.

    One other benefit of this method was that one app couldn't possibly crash the entire system, or nGhost.

    In nGhost2 (ng2), this ideology didn't play out how we would have hoped. It suffered from major flaws. The Toolkit was too cumbersome to create separate apps quickly, and IPC communication was equally cumbersome to setup to facilitate proper communication. Because of these flaws, eventually nGhost's plugin system replaced the multi-process ideology.

    The popularity of google chrome has lead me to revisit the idea. As you may know, each tab in the chrome browser is essentially a separate process with a narrow IPC lane to facilitate communication. If one page crashes, it simply kills the tab... chrome still runs as if nothing ever hit it.

    I have proposed we evolve the ideas of ng2, fix the issues in a new roll-out: nGhost3 (ng3).

    To illustrate the architecture plans for ng3, I must first explain the different components involved in the system and what their roles are:

    NDM - nGhost Desktop Manager
    In and *nix environment it is common to have a desktop manager. GDM on GNOME (stock ubuntu also), KDM on KDE, etc. Traditionally, these Desktop Managers facilitate multi-user logins and start the graphical session for the user that logs in.

    In a system such as OpenICE, which is within usually a single-user environment (with autologin a must), no existing desktop manager would suffice. In the 1.0 platform, no DM is used, simply an autologin script and "startx".

    NDM will take over the DM role in OpenICE post 1.0. It will facilitate autologin for single users, facilitate multi-user logins in a more mobile friendly way, and also act as a process owner for ng3-core. In addition to these, its primary role will be to facilitate a window layout system, and track all the loaded plugins.

    ng3-toolkit
    this is not a process, but a library of functions for plugins to draw look/feel consistent GUI elements such as buttons, listboxes, dials/guages, etc.

    ng3-server

    This is the hub of the ng3 system. It's main role will be to pass communication between plugins.

    The server instance will be owned and started by NDM with all the plugins enabled on the system.

    ng3-core
    ng3-core is a child process to the ng3-server. It runs a single plugin.

    ng3-plugin
    a ng3-plugin is similar to any plugin. It inherits from some interface, and implements some functions. a plugin can be a graphical plugin that uses the ng3-toolkit, or a pure code plugin with no graphical interface.

    Default Plugins
    Icepanel, will be a default plugin along with an audio-device interface, and possibly some others.

    plugin loading

    WHen NDM logs in, it will start ng3-server. It will also keep an IPC handle of that core. Then NDM will start loading plugins. NDM can do this in two ways, in embedded mode, NDM will pass a message to the ng3-server to create a new window. NDM will then start up a client-core with that plugin and pass it the server IPC handle and the window ID for the clent core to embed itself in the server.

    In non-embed mode, the plugin will be loaded into a new client-core instance with a handle to the ng3-server in its own window.

    When ng3-core loads with the new plugin, it will ask NDM via IPC where it should draw it's window and how large.

    finally ng3-core will then register an icon for the plugin on icepanel so the user can switch between it and the other plugins. A plugin can also register additional controls on icepanel if it so needs/choses.

    icepanel
    In case you don't know the openice system, icepanel is a dock application for the purpose of exposing controls and launchers from applications that need to persist their controls across multiple screens. In pre-1.0, icepanel, nscan, and nGhost were the only separate process plugins that utilized the nghost IPC mechanism for communication.

    Conclusion

    In short, by implementing a multi-process FE system, the entire system can be more secure/stable, and utilize things like existing window managers for extra usability and eyecandy. This system also by nature takes advantage of multiple cores/processors (think atom 330 dual-core and the new 550 that will soon be released). The server still embed bypassing the window manager or can allow plugins in separate windows yet still maintain the same embedded look/feel that is expected in mobile systems.

    Plugins are developed in a traditional manner yet still benefit from communcation method to other plugins and the main server and they don't have to worry about sharing the CPU with other plugins on a single-threaded/single-process design.

    The idea is simple, but the devil is always in the details and implementation. I'm interested to hear what others think about the idea.

    Questions? Comments?
    Former author of LinuxICE, nghost, nobdy.
    Current author of Automotive Message Broker (AMB).
    Works on Tizen IVI. Does not represent anyone or anything but himself.

  2. #2
    Newbie
    Join Date
    Jun 2007
    Posts
    49
    Maybe a graphic to display the way the comunicate would help understanding a little better. Sounds good other wise, where do we start.

  3. #3
    licensed to kill - FKA kev000
    Auto Apps:loading...
    tripzero's Avatar
    Join Date
    Aug 2006
    Location
    16.40618, 120.61106
    Posts
    2,494
    Here's a weak openoffice attempt:

    Name:  screenshot1.jpg
Views: 294
Size:  18.7 KB
    Former author of LinuxICE, nghost, nobdy.
    Current author of Automotive Message Broker (AMB).
    Works on Tizen IVI. Does not represent anyone or anything but himself.

  4. #4
    Variable Bitrate
    Join Date
    Aug 2005
    Location
    MD
    Posts
    238
    If it makes nGhost more stable and secure then I'm all for it. I do have one question, does this new concept affect performance at all? I understand that each process is almost separate and will not crash the OS, but will new processes mean a higher CPU load? I'm ultimately thinking about adverse performance effects on slower carPC's like my MII10000.

  5. #5
    North of the land of Hey Huns
    Auto Apps:loading...

    Join Date
    Jun 2004
    Location
    Westminster, MD
    Posts
    2,127
    As I understand it (And I've not had more than a short discussion with kev on this):

    The core system should run fast enough (if programmed correctly *nudge nudge*), however it will be on the plugin developers to write plugins (as independent processes) that don't use up too much processor time. Hopefully trip will work in some kind of scheduling into the event system?
    "stop with the REINSTALLS, what do you think we got some lame-o installer!!!" - mitchjs
    RevFE
    My Shop

  6. #6
    Variable Bitrate
    Join Date
    Aug 2005
    Location
    MD
    Posts
    238
    That's good to hear. While I'm no programmer, it would be nice to see process priority built into the code. For instance, I give high priority to certain processes based on my personal preference. I could make the Music, GPS, Video and Visualizations top priority all the time. But if I'm running other apps like a calculator, calendar or web browser then I would give this intermediate or low priority to keep certain processes, that I decide, running smoothly. I'm not really sure who practical or feasible this is, but it's just a thought.

  7. #7
    licensed to kill - FKA kev000
    Auto Apps:loading...
    tripzero's Avatar
    Join Date
    Aug 2006
    Location
    16.40618, 120.61106
    Posts
    2,494
    It should run snappy on even slower processors (if coded properly ). The main concern on the MII10000 will be getting opengl to work correctly so ng3 will even show up. I hear via has new drivers, but I haven't tested them in a while.
    Former author of LinuxICE, nghost, nobdy.
    Current author of Automotive Message Broker (AMB).
    Works on Tizen IVI. Does not represent anyone or anything but himself.

  8. #8
    Variable Bitrate
    Join Date
    Aug 2005
    Location
    MD
    Posts
    238
    Quote Originally Posted by kev000 View Post
    It should run snappy on even slower processors (if coded properly ). The main concern on the MII10000 will be getting opengl to work correctly so ng3 will even show up. I hear via has new drivers, but I haven't tested them in a while.
    Would it be possible to lower graphic effects/eye candy similar to PC games?

  9. #9
    licensed to kill - FKA kev000
    Auto Apps:loading...
    tripzero's Avatar
    Join Date
    Aug 2006
    Location
    16.40618, 120.61106
    Posts
    2,494
    Quote Originally Posted by matt11601 View Post
    Would it be possible to lower graphic effects/eye candy similar to PC games?
    I proposed the idea that every "actor"/widget's eye-candy effect be pluggable. So in theory, you should be able to turn off individual widget's effects. However, you won't be able to turn off OpenGL rendering, and that maybe a problem with some hardware/drivers.

    On a side note, Clutter supports OpenGL ES rendering. So that means that it should run on the iPhone, MID, or other similar device. (iPhone doesn't have DBus either, so I'm really not sure if it'll run there... )
    Former author of LinuxICE, nghost, nobdy.
    Current author of Automotive Message Broker (AMB).
    Works on Tizen IVI. Does not represent anyone or anything but himself.

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •