3

I was googling and searching SO for plugin architecture and I'm satisfied by general knowledge on how to implement it. Now I went further to look for a sandboxed architecture. Basically what I mean is an application with plugin whereby crashing in plugin won't crash the whole app and the plugin can be reloaded. I cannot find good documentation. I know Firefox implements it (crashing flash plugin does not affect whole FF thing and can be reloaded) Thanks!

Stefano Mtangoo
  • 6,017
  • 6
  • 47
  • 93
  • 3
    I think you need the plugin to run in its own process, so that it doesn't tear down the host app when it crashes. That requires the communication between plugin and host app to be interprocess communication, though. – sbi Sep 21 '11 at 19:03
  • 2
    @sbi, this should be an answer – bdonlan Sep 21 '11 at 19:04
  • @bdonlan: Nah, it's not worth it. (Go for it, if you think.) – sbi Sep 21 '11 at 19:06
  • @sbi, but then if I have 20 plugins that is 20 processes. Isn't that overhead of resources as well as interprocess communication? AFAIK, processes are hard to share resources – Stefano Mtangoo Sep 21 '11 at 19:14
  • @Stefano: Shared resources are potential points of failure. If the plugin corrupts something, and it's isolated, you're fine. If the plugin corrupts something, and it's shared with the main application, you're in for a world of hurt. – Ben Voigt Sep 21 '11 at 20:23
  • @Stefano: That depends on what you need. FF has only one plugin host process for all plugins. That way plugins can kill each other, but not their host application. – sbi Sep 22 '11 at 05:51

2 Answers2

8

The only way you can have a truly sandboxed architecture wherein a plug-in cannot directly crash the parent application's process or corrupt its memory is by placing it into a separate OS process, with a separate memory space. When doing this, you will need to rely on interprocess communication facilities of the OS (pipes, sockets, remote procedure calls, memory mapped files, shared memory, synchronization objects, etc.) to interact with the plug-in.

vercellop
  • 553
  • 5
  • 18
  • that would make app complex when plugins are many. Suppose 20 plugins and all memory space and interprocess communication. At least if there could be two processes running one hosting all plugins and other core app. – Stefano Mtangoo Sep 21 '11 at 19:17
  • 2
    Yes, if it's OK for plug-ins to potentially interact with one another, you could have a single plug-in host process for all plug-ins. It may make recovery of the plug-in host more complex if it dies - to use the Firefox comparison, it would mean that if a plug-in misbehaves and takes down the hosting process, all open pages that use any plug-in would have to be reset in some way, as opposed to potentially resetting only one page / plug-in instance. – vercellop Sep 21 '11 at 19:27
  • Mh! I think there is no way than what you have in your answer. Let me wait if there is any other alternative before I accept it as an answer. Thanks vercellop – Stefano Mtangoo Sep 21 '11 at 19:56
  • I think this is the solution that is practical as far as I can see! Thanks all! – Stefano Mtangoo Sep 22 '11 at 16:21
3

Google's native client technology may be more thorough than what you were looking for, but it might be worth a read.

Nicola Musatti
  • 17,834
  • 2
  • 46
  • 55