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

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

[Eugene Gorodinsky]

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

Suppose you're writing an app such as a multiprotocol instant messenger or a
mediaplayer that supports multiple container formats and codecs. It's a good
idea for your app to have a plug-in functionality, so that plugins could be
developed independently and functionality added to the program without the
need to recompile the whole thing. On a system that supports dynamic linking
this is trivial. On Plan9 I'm not sure how to go about this. Having separate
processes interacting with the main one seems somewhat wrong to me (slower,
more overhead etc). Perhaps it's better to implement a limited form of
dynamic linking, so that modules compiled to load dynamically could be
loaded by the application that wants to load them whenever it needs. What do
you think?

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

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

[Lucio De Re]

On Fri, Dec 10, 2010 at 11:34:41AM +0200, Eugene Gorodinsky wrote:
> Date: Fri, 10 Dec 2010 11:34:41 +0200
> From: Eugene Gorodinsky <e.gorodinsky@gmail.com>
> To: 9fans@9fans.net
> Subject: [9fans] How would you go about implementing this in Plan9?
>
> Suppose you're writing an app such as a multiprotocol instant messenger or a
> mediaplayer that supports multiple container formats and codecs. It's a good

You build them all into the synthetic files server, but only activate the
needed ones as commanded through a control channel or file.  In such
case, you can define the communication mechanism and may do better
than with loadable modules, where you can never be certain that they'll
be available.

++L

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

[hiro]

How much overhead are we talking about?

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

[hiro]

Sometimes simple traditional apps with stdin and stdout will also suffice...

On 12/10/10, Lucio De Re <lucio@proxima.alt.za> wrote:
> On Fri, Dec 10, 2010 at 11:34:41AM +0200, Eugene Gorodinsky wrote:
>> Date: Fri, 10 Dec 2010 11:34:41 +0200
>> From: Eugene Gorodinsky <e.gorodinsky@gmail.com>
>> To: 9fans@9fans.net
>> Subject: [9fans] How would you go about implementing this in Plan9?
>>
>> Suppose you're writing an app such as a multiprotocol instant messenger or
>> a
>> mediaplayer that supports multiple container formats and codecs. It's a
>> good
>
> You build them all into the synthetic files server, but only activate the
> needed ones as commanded through a control channel or file.  In such
> case, you can define the communication mechanism and may do better
> than with loadable modules, where you can never be certain that they'll
> be available.
>
> ++L
>
>

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

[Lucio De Re]

On Fri, Dec 10, 2010 at 10:46:43AM +0100, hiro wrote:
>
> How much overhead are we talking about?

In a real-time environment, it's easiest to think of all overheads as
being bad, even though often they don't have any noticeable impact.

++L

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

[Charles Forsyth]

>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.

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

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.

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

[Eugene Gorodinsky]

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

I came across dyncall. Is that the library you were talking about? If there
already is an existing library out there, then I might experiment with both
approaches.

2010/12/10 Charles Forsyth <forsyth@terzarima.net>

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

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

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

[Federico G. Benavento]

what about a pipe?
juke spawns /bin/games/mp3dec, page, png(1), jpg(1), etc
there's even an avidec somewhere intended to be used that way, if I'm not
mistaken.

On Fri, Dec 10, 2010 at 6:34 AM, Eugene Gorodinsky
<e.gorodinsky@gmail.com> wrote:
> Suppose you're writing an app such as a multiprotocol instant messenger or a
> mediaplayer that supports multiple container formats and codecs. It's a good
> idea for your app to have a plug-in functionality, so that plugins could be
> developed independently and functionality added to the program without the
> need to recompile the whole thing. On a system that supports dynamic linking
> this is trivial. On Plan9 I'm not sure how to go about this. Having separate
> processes interacting with the main one seems somewhat wrong to me (slower,
> more overhead etc). Perhaps it's better to implement a limited form of
> dynamic linking, so that modules compiled to load dynamically could be
> loaded by the application that wants to load them whenever it needs. What do
> you think?



--
Federico G. Benavento

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

[erik quanstrom]

> this is trivial. On Plan9 I'm not sure how to go about this. Having separate
> processes interacting with the main one seems somewhat wrong to me (slower,
> more overhead etc).

that's single-core think.  today splitting things up into multiple
processes is a good way to reduce latency or increase speed.

- erik

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

[David Leimbach]

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

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: 2200 bytes --]

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

[Eugene Gorodinsky]

[-- 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 --]

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

[Federico G. Benavento]

On Fri, Dec 10, 2010 at 5:01 PM, Eugene Gorodinsky
<e.gorodinsky@gmail.com> wrote:
> 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.
>

so the UI doesn't hang because webkit is single threaded, so you just
fork()/exec() a binary
and communicate via a named pipe?

in any case, like chrome, which uses some sort of shared bitmap for a
media player
the player could create and image and share it via nameimage(), then the decoder
program would just call namedimage() to get that one and draw to it...
hell it could draw directly to the display with image id 0 if you want
it, so really

for the im client a pipe is more than enough

--
Federico G. Benavento

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

[Nathaniel W Filardo]

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

On Fri, Dec 10, 2010 at 01:21:49PM +0200, Eugene Gorodinsky wrote:
> I came across dyncall. Is that the library you were talking about? If there
> already is an existing library out there, then I might experiment with both
> approaches.

The other, older library is dynld.  The "official" release is available
somewhere and mirrored here: http://gsoc.cat-v.org/people/nwf/dynld.tgz .
Ages and ages ago I wrote a small extension to its API, resulting in
http://gsoc.cat-v.org/people/nwf/dynld-nwf.tgz .  Some (old-QEMU-internals
inspired) commentary can be found in http://gsoc.cat-v.org/people/nwf/dynld .

--nwf;

[-- Attachment #2: Type: application/pgp-signature, Size: 205 bytes --]

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

[Eugene Gorodinsky]

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

2010/12/10 Federico G. Benavento <benavento@gmail.com>

> On Fri, Dec 10, 2010 at 5:01 PM, Eugene Gorodinsky
> <e.gorodinsky@gmail.com> wrote:
> > 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.
> >
>
> so the UI doesn't hang because webkit is single threaded, so you just
> fork()/exec() a binary
> and communicate via a named pipe?
>
> in any case, like chrome, which uses some sort of shared bitmap for a
> media player
> the player could create and image and share it via nameimage(), then the
> decoder
> program would just call namedimage() to get that one and draw to it...
> hell it could draw directly to the display with image id 0 if you want
> it, so really
>
> By sharing a bitmap, do you mean using shared memory between different
processes? I'm still not comfortable with having executables that can't do
anything on their own. Kind of pointless to have them if they can only work
when spawned by another process.


> for the im client a pipe is more than enough
>
Hmm... perhaps.

>

--
> Federico G. Benavento
>
>

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

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

[Eugene Gorodinsky]

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

Interesting. Thanks.

2010/12/11 Nathaniel W Filardo <nwf@cs.jhu.edu>

> On Fri, Dec 10, 2010 at 01:21:49PM +0200, Eugene Gorodinsky wrote:
> > I came across dyncall. Is that the library you were talking about? If
> there
> > already is an existing library out there, then I might experiment with
> both
> > approaches.
>
> The other, older library is dynld.  The "official" release is available
> somewhere and mirrored here: http://gsoc.cat-v.org/people/nwf/dynld.tgz .
> Ages and ages ago I wrote a small extension to its API, resulting in
> http://gsoc.cat-v.org/people/nwf/dynld-nwf.tgz .  Some (old-QEMU-internals
> inspired) commentary can be found in
> http://gsoc.cat-v.org/people/nwf/dynld .
>
> --nwf;
>

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