[coyotos-dev] DLL's

[Jonathan S. Shapiro]

On Wed, 2007-05-23 at 14:18 -0400, Christopher Nelson wrote:


Hmm. My take on DLLs is that they fall into two niches.  
> 
> (1) Remote API - the DLL lets you communicate with something, usually
> a server or a device by way of a driver.
> (2) algorithms, like the c++ standard library, that are pretty
> integral to your code, and are also generally performance sensitive. 
> 
> It seems like (1) abstracts pretty well into small objects, and you
> are provided with an interface specification that allows you to talk
> to them.  Since you generally have context switches in these cases
> anyway, using IPC isn't really a big deal, IMHO. 

I tend to agree.

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

> For example, say I have a media player.  It uses a particular
> algorithm library that includes memory allocation.  I also want to
> allow plugins.  I am concerned about performance, so my thought is
> that I should be able to instantiate a plugin's code as a Process in
> my current address space.  Then I don't have to copy data to other
> address spaces, and I don't have to incur context switches.  

The media player plugin is a great example of where you should NOT do
this, because it makes the player as a whole completely unrecoverable if
corruption occurs within the plugin. Consider how often the xine plugin
craps out the entire firefox image.

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.

> Granted, each plugin could use their own memory allocation routines,
> but my media player has a highly optimized allocation routine
> specifically designed for the access patterns I know playing media
> will evince.

Yes, but consider that you have to trade-off concurrency overheads vs.
IPC. That CAS instruction down in the malloc() implementation takes
several hundred cycles...

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

Fortunately, Linux and Windows coders look quite striking dressed in
vegetable matter. :-)



shap