Re: [9fans] How would you go about implementing this in Plan9?

[Eugene Gorodinsky <e.gorodinsky@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1845 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2718 bytes --]