Reminds me of a storyIf either process becomes unstable it can be restarted from the other
After some tough debate we have decided to implement some architecture changes to the OpenMobile framework. While this will slightly effect the compact monolithic design of the framework we feel the benefits will far outweigh the disadvantages.
As of now Open Mobile is a single process that runs each plugin on a sandboxed thread to maintain stability and responsiveness. We are quite happy with the performance of keeping all communications in-process. However, in order to best maintain functionality on all target platforms we have decided to transition to a two process approach. While this does add some complexity to the design, this complexity should be transparent to both plugin designers and end users.
The new two process approach will consist of the openMobile core process and a platform specific OS interface process (running as a service). Long story short...
Advantages of the new design:
- All unmanaged and potentially unsafe code (native calls) is now running in a separate process. Calls between the two processes use a message bus to prevent failure propagation.
- If either process becomes unstable it can be restarted from the other further increasing the stability of the application as a whole (aka it would most likely take a hardware failure to cause a full software crash)
- Only code specific to your operating system will be deployed saving space and potential confusion
- Native interfaces will be much easier (and potentially more stable) to implement since there will be no cross-platform compatibility restrictions
Disadvantages of the new design:
- Message bus adds a tiny delay although testing shows this to be negligable
- Complexity of running two processes instead of one
Some techy details:
- The message bus is being called U-bus and is a very lightweight binary UDP protocol (ports 8549 and 8550)
- The Windows process will run as a windows service and interface directly with the windows API
- The Linux process will be a GTK application running in the background and interfacing with dbus
- The Mac application will likely be on hold until the first two services are created or until a Mac developer steps up
So is this kinda like a mythtv-like frontend/backend approach? What does this openMobile Core do? Are the plugins running as separate processes? I'm wondering how close far this design is from the nGhost3 design...
Gary: my eyes glazed over attempting to read that "story". That and my ADD prevents me from reading something that long . I was like 4 years old in 1988, and I really never grew up.
Former author of LinuxICE, nghost.
Current author of nobdy.
linux. On windows, having message callbacks on a form that wasn't drawing has some obvious performance benefits along with the whole dual process stability thing.
Plugins still run within sandboxed threads inside the core process. The core still contains pretty much the same stuff including all the controls, plugin routing and useful functions. The only difference is that things like wifi, disk insertion and volume change notifications will be passed to the core from a separate process. On windows this will also pass directshow notifications to the media player. On Linux, this will provide some dbus notifications to the respective media player plugins as well.
Why don't dbus callbacks work with winform apps? You can use it without the gtk mainloop, you just have to call Bus.Iterate() on a timer or thread or something. I assume you tried using NDesk.DBus?No its still a LONG way from nGhost but I think it gets the best from both worlds. Initially I was going to do an OSSpecificLib dll for each platform but after some trial and error found out that dbus callbacks wont work with winforms applications, and since there are no gtk apps for .net (only mono) I would need separate processes to hook dbus signals on linux. On windows, having message callbacks on a form that wasn't drawing has some obvious performance benefits along with the whole dual process stability thing.
So the difference is ng3 system is a one to many process arch and openMobile is a one to one? And the reason you split them up is to take advantage of platform specific stuff like wifi, DeviceKit, etc?Plugins still run within sandboxed threads inside the core process. The core still contains pretty much the same stuff including all the controls, plugin routing and useful functions. The only difference is that things like wifi, disk insertion and volume change notifications will be passed to the core from a separate process. On windows this will also pass directshow notifications to the media player. On Linux, this will provide some dbus notifications to the respective media player plugins as well.
Former author of LinuxICE, nghost.
Current author of nobdy.
First things first.. HEY-O notifications are back!!!
Apart from the fact you probably meant "process" and not "thread" - IPC /a la/ dbus is *cheap*. IPC /a la/ sockets or even shared memory is even cheaper.Pretty much....we can fully sandbox each thread since its managed code, which gives the same stability benefit without the performance loss of interprocess coms (or at least thats the theory behind it).
In this day and age, I don't feel that that's a legitimate concern.
From a developer's perspective, it's *shameful*. If the API documentation tells you, in bold, that by using it you are "signing up for some pain", then perhaps, just perhaps, that's something of a red flag. Having used the dbus API, I hope it just curls up and dies. I realise that wrappers make it a lot easier, and are the recommended way of using dbus, but at some point one has to wonder if there aren't better options out there when the developers of the project tell you not to use it.
Of course, if you've evaluated all of the RPC mechanisms out there and found that dbus works the best for your needs, then great. But by the sounds of it your needs include "cross-platform support", and apparently it doesn't actually work for you on windows.
Well yes and no, dbus itself is cheap but any type of platform neutral IPC object passing is going to require passing pointers, which chances are will get very ugly when some of the developers around here try to use them. The goal here is to design a system thats (for lack of a better phrase) idiot proof.
requirements. For example, I can fully interact with VLC using 20 lines of code. if I tried doing that with static calls it would be 10x that minimum plus the added trial and error of getting it working. Same thing for a dozen different system events which would require hundreds of lines of code along with hours and hours of reading up on the docs on each of the different libraries, it just makes sense.
Of course its not 100% crash proof, unmanaged code or api calls can probably take down the entire process, but we try to avoid that as much as possible. And now even if something like that happens, the background service can revive it.