[coyotos-dev] DLL's

[Christopher Nelson]

>
> > The second case is much more interesting.  Mostly because I wondered
> > how much use you are planning to make of the fact that multiple
> > Processes can share the same address space.
>
> Yes. Also, these algorithms tend to remain stable over time. But these
> cases are interesting for a different reason as well: in many cases you
> have to instantiate those algorithms over some object type (consider
> templates). The instantiation causes the code to become app-specific.



I hadn't thought about that.  It's a good point, though.  In many of these
(algorithmic) cases you aren't saving a whole lot of space by using DLLs.


The interesting thing about plugins is that you don't call them often,
> and you often expect them to run for a while when you do. In this case
> the IPC is no big deal -- the bigger issue is finding a way to share the
> frame buffer safely and recoverably, which actually isn't that hard.


I was thinking of, e.g. filters for the output data, but I suppose that is
the same as having a shared video frame buffer.

> I can see that this is probably not a big challenge in many ways,  but
> > I wonder about the feasability of having common objects, like plugins,
> > that you import as whole executable objects into your address space.
> > Is this a paradigm that you plan on supporting in general?  ie. Out of
> > the Box?
>
> Our design goal is to prefer idioms that favor robustness. We wouldn't
> contemplate anything that would prevent the pattern you are considering,
> but we're perfectly comfortable throwing rotten vegetables at people who
> use those patterns without a really compelling rationale (which would
> certainly want to include hard measurements).
>
>
I am curious about performance measurements here as well.  I have been
looking forward to using Coyotos for a long time. :-D
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.coyotos.org/pipermail/coyotos-dev/attachments/20070523/328a37eb/attachment-0001.html