Joe Beda - Managed vs. unmanaged, how much of Avalon was done that way?

Are you at liberty to discuss how this has evolved. For example were there considerable portions of managed code that had to be moved over to unmanaged for tweaking purposes ? or unmanaged code that was migrated to managed because it was cleaner to handle and maintain ?

daniel wrote:

Are you at liberty to discuss how this has evolved. For example were there considerable portions of managed code that had to be moved over to unmanaged for tweaking purposes ? or unmanaged code that was migrated to managed because it was cleaner to handle and maintain ?

I can speak to this a little bit.  Originally, we didn't know if we were going to have to deliver an unmanaged API to go along with our managed API.  To do this, we implemented our visual (basically a node in our display tree) in unmanaged code with managed wrappers.  We hit real problems with lifetime management when we wanted to attach any sort of managed data to our unmanaged objects.  This happened when we let users attach data to the visuals (think SetWindowPtr) or try to call back into managed code (think WM_PAINT). WinForms handles this type of thing (I think) with hash tables and explicit lifetime management.  Neither of those is efficient enought or clean enough for where we wanted to go with Avalon.

The basic problem is that if you have a well connected object graph, it doesn't work well split across the managed/unmanaged boundary.  The simple way to do this is to have everything that unmanaged code is holding on to be a GC root.  This means that the GC won't see through unmanaged code to collect the managed object held on to by managed code.  To put it in concrete terms, suppose you have a managed object A (Am) that is holding on to an unmanaged object B (Bu).  No suppose that Bu is holding on to a managed object C (Cm).  Now suppose (directly or indirectly) Cm is holding on to Am.  In this situation we have a reference loop that goes through unmanaged code.  Even if there are no external references holding on to any of these objects, the GC will never know to collect them as it can't trace the indirect reference from Am to Cm.

The upshot is that you really want the transition layer to be as "one way" as possible.  APIs like GDI+ (System.Drawing) or DX work well because they rarely call back or hold on to managed user data.  APIs like WinForms (which is, amoung other things, a wrapper on USER) have to bend over backwards to straddle the line like they do.

Internally, we moved a bunch more stuff over to the managed side so that we could make our API be more "one way".

Thank you, this is exactly the type of answer I was interested in.