FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Slow Going

 
Post new topic   Reply to topic     Forum Index -> DSP
View previous topic :: View next topic  
Author Message
pragma



Joined: 28 May 2004
Posts: 607
Location: Washington, DC

PostPosted: Sat Mar 12, 2005 9:28 pm    Post subject: Slow Going Reply with quote

Very Happy The last month of coding has been a grueling exercise, with Real Life (tm) stepping in where necessary.

I *finally* have a solution to using dll's as class factories, w/o all the nasty overhead that COM provides. D's type system, and ABI made this possible, although not with the typical out-of-the box kit.

First it was the improvments made to make the GC 'hookable' across dll boundaries. As I've mentioned before in this forum, this causes problems with objects that depend on the dll space for their vtables. After much hacking, I abandoned this approach and went back to the multiple-GC way of doing things.

Then I stumbled into a strange bug, regarding cast() operations that "killed" objects. My efforts led me to the very definition of cast() itself, in the DMD/phobos internals.

As it turns out, the way objects and typeinfo is laid out, three native forms of cast() exist. One for casting objects to interfaces, one for object to object casts and another for void* type casts (static casting). The two dynamic casts both try to match by typeinfo reference for a valid match, which usually isn't a problem.

However, when one 'talks' to a dll in D, they are really talking to a separate instance of phobos, with a complete typeinfo tree inside. No measure of dynamic casting of dll-created objects will yield a match as the typeid of the provided type will *never* match anything associated with the object.

The solution for this is very simple: cast by classname instead. I rolled my own cast operator that uses the ABI to walk an object's lineage in order to find a match; checking by classname all the way.

Keep in mind that as radical as rolling a new cast operator may seem, it parallels what Microsoft COM has been doing all along. This operator, plus the D typeinfo system is a complete replacement for QueryInterface(). No more lookup tables and no more long switch statements.

The last mile, is covered by hand-coded proxies in the host program. As much as I want to do without such stub-code, its needed for the dll-reload semantics to function correctly.

Arrow DSP's TypeLibrary interface uses a sibling interface "IExportable" which marks a class as able to "jump the transom" between a dll and a host executable. The complete kit has the following features:

- Drop in stubs for dll and TypeLibrary creation
- Common interface for mainipulating TypeLibrary-style dlls
- Reload-resilient object proxies (great for debugging!)
- Library and LibraryCache classes for fast library access

Mixins are used to good effect to make coding easy:

Code:

// in a common .d file
class IMyClass{
    void mymethod();
}

// in the dll only
class MyClass: IMyClass, IExportable{
    mixin ExportClass!(MyClass);
    mixin ExportableAdapter!(); // get common methods
    this();  // required
    void mymethod(){}
}

// in the host program only
class MyClass{
    mixin ExportableProxyMixin!(IMyClass);
    void mymethod(){
        getInstance.mymethod();
    }
}

void main(){
    TypeLibrary tlb = new TypeLibrary("mylib.dll");
    MyClass mc = new MyClass(tlb.getInstance("MyClass"));
    mc.mymethod();
}


(the interface may go through some slight changes before release)

Exclamation There are the typical caveats of sharing data between the dll and the host executable. Right now, these are a huge issue as externalizing the GC in the dll doesn't play nice with object references (calls non-existant destructors on fullCollect). Once that's solved, only the exported object proxies will remain to enforce correct reloading behavior.

Rolling Eyes Anyway, the entire point to this exercise is to create a testbed (Mango) server for DSP that will be flexible enough to support drop-in sub-servers. One of those will be DSP. The other goal, was to make a server that is flexible enough to use a generic configuration script, akin to apache. In a very crude way, this goal has been met on my development machine, using the expat parser to load XML config data into dynamically loaded server libraries.

The 1.0 release of DSP will have no less than the DSP engine itself. I hope to provide the dynamic testbed server framework along with it, so everyone can start coding in DSP from the word 'go'.
_________________
-- !Eric.t.Anderton at gmail
Back to top
View user's profile Send private message Yahoo Messenger
Display posts from previous:   
Post new topic   Reply to topic     Forum Index -> DSP All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group