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

[Eugene Gorodinsky]

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?

[hiro]

How much overhead are we talking about?

[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.goro...@gmail.com>
> To: 9f...@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

[hiro]

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

[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

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

[Eugene Gorodinsky]

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 <for...@terzarima.net>

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

--
Federico G. Benavento

[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

[David Leimbach]

On Fri, Dec 10, 2010 at 2:30 AM, Charles Forsyth <for...@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 :-)

[Eugene Gorodinsky]

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 <lei...@gmail.com>

[Federico G. Benavento]

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

[Nathaniel W Filardo]

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;

[Eugene Gorodinsky]

Interesting. Thanks.

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

[Eugene Gorodinsky]

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

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