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 <[email protected]> > > > On Fri, Dec 10, 2010 at 2:30 AM, Charles Forsyth <[email protected]>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 :-)
