From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <7a892f212376bb182f0c323f8ec320e1@terzarima.net> References: <7a892f212376bb182f0c323f8ec320e1@terzarima.net> Date: Fri, 10 Dec 2010 07:52:01 -0800 Message-ID: From: David Leimbach To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=0016e64549f2d4faf80497105586 Subject: Re: [9fans] How would you go about implementing this in Plan9? Topicbox-Message-UUID: 8b6ebdbe-ead6-11e9-9d60-3106f5b1d025 --0016e64549f2d4faf80497105586 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Dec 10, 2010 at 2:30 AM, Charles Forsyth 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 :-) --0016e64549f2d4faf80497105586 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

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

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

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

in your particular applications, on modern hardware, i shouldn't think<= br> 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).

<= div>The multi-process/service approach makes better use of multiple cores i= n an OS than a traditional plugin architecture might with a single thread o= f execution.
=A0

having said that, plan 9's loader has got support for creating dynamica= lly loaded things,
with type checking. there's a supporting library that provides a reason= able
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 :-) --0016e64549f2d4faf80497105586--