Thread: Architecture Changes

If either process becomes unstable it can be restarted from the other

Reminds me of a story

Gary (-;

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.

Originally Posted by chunkyks

Reminds me of a story

Gary (-;

I had to go over that twice to figure out what you were going for lol.... Yea similar concept except without the security risk.

Originally Posted by kev000

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.

I knew you would jump all over that thought 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.

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.

Originally Posted by justchat_1

I knew you would jump all over that thought

yeah, I'm a sucker for architecture discussions...

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.

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?

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.

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?

First things first.. HEY-O notifications are back!!!

Originally Posted by kev000

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?

Yea thats how its supposed to work but I've used exactly the same code with a winforms app and a gtk app and only the gtk app worked properly. When using bus.iterate() in a loop and tracing it, it does iterate every time a signal is raised but mono eats the notification with winforms so the callback is never fired.

Originally Posted by kev000

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?

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).

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).

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.

In this day and age, I don't feel that that's a legitimate concern.

The Linux process will be a GTK application running in the background and interfacing with dbus

Why all this love for dbus? I just don't get why people like it.

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.

Gary (-;

Originally Posted by chunkyks

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.

In this day and age, I don't feel that that's a legitimate concern.

Nope I did mean thread, even though its not a very common concept. Traditionally we think of processes sandboxed from the operating system. In this case we are actually sandboxing a thread. Any type of errors that occur within the thread is trapped locally, logged and then the thread is restarted. All interprocess coms go through a pluginHost which completes the barrier necessary to sandbox the plugins. Its a little bit odd but the results have worked perfectly so far.

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.

Originally Posted by chunkyks

Why all this love for dbus? I just don't get why people like it.

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.

Personally i'm no longer a dbus fan but it is 100x better then the alternative in terms of development 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.

Originally Posted by justchat_1

Nope I did mean thread, even though its not a very common concept. Traditionally we think of processes sandboxed from the operating system. In this case we are actually sandboxing a thread. Any type of errors that occur within the thread is trapped locally, logged and then the thread is restarted. All interprocess coms go through a pluginHost which completes the barrier necessary to sandbox the plugins. Its a little bit odd but the results have worked perfectly so far.

How is this different from traditional top-level exception catching? How do you stop a thread from loading something that potentially crashes it, therefore taking out the parent application if it's all in the same process?

Originally Posted by malcom2073

How is this different from traditional top-level exception catching? How do you stop a thread from loading something that potentially crashes it, therefore taking out the parent application if it's all in the same process?

Two ways.... 1-we catch and eat the exception before it gets to the top level (and terminates the application) and 2-plugins do almost everything using the framework which handles a lot of the common mistakes. I should add not all of this is in the latest svn but its coded and working.

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.