There's a lot more reasons for using one tab = one process approach. For chrome it really is a bargain. But for a non-browsing application it might not be so.

2010/12/10 David Leimbach <leimy2k@gmail.com>


On Fri, Dec 10, 2010 at 2:30 AM, Charles Forsyth <forsyth@terzarima.net> wrote:
>On a system that supports dynamic linking this is trivial.

it's usually error prone, for instance there's no type checking,
and dangerous: the main application crashes each time a plug-in blows a fuse,
because dynamically loaded things are simply read in to the same protection domain.

Which is why Google's Chrome runs different tabs in different contexts, to help prevent bringing down the whole browser due to plugin fragility.
 

in your particular applications, on modern hardware, i shouldn't think
have trouble with the overhead of connecting separate processes,
especially the instant messenger one, but with care in design the
mediaplayer should work too. after all, in both cases you can't
send faster than the network, and in the latter you can't display
faster than humans can see it, so there's quite a bit of slack.
the main problem in the latter is maintaining a steady flow
(the EDF scheduling might help you there).

The multi-process/service approach makes better use of multiple cores in an OS than a traditional plugin architecture might with a single thread of execution.
 

having said that, plan 9's loader has got support for creating dynamically loaded things,
with type checking. there's a supporting library that provides a reasonable
interface to it, but that's not part of the distribution.
if there's not already a copy somewhere i'll dig it out again.

Pretty interesting :-)