I'm digging around in the source for the XPCOM proxy implementation. Trying to determine how things work and how we should go about implementing some cross thread notification stuff for songbird. In particular we want to move from our current dataremote system which uses prefs to pass only strings, integers and booleans around to a system that can pass nsISupports pointers and objects around. We're planning on using this system for publishing the progress of background jobs and want to be able to reflect that in the UI, so we're looking into ways to proxy notification calls from background threads to the UI thread, or just to any old thread you might be on.
More in the extended text...
]]>
The hope was that the proxification step would only happen if the notification was coming on a different thread. But that doesn't appear to be the case. Instead it all depends on whether the calling code is on a different thread then the one passed to the ProxyManager. As you can see in the implementation for nsProxyObjectManager::GetProxyForObject. If the requested event queue is on a different thread from the code of the caller then a proxy is created (or found and returned); if the thread is the same then the object is just handed back. Now I knew that the original object would get called ( as opposed to the proxy ) in some cases but I was hoping it would be if the actual call occured on a different thread than then the requested, not if the proxy was obtained on the same thread.
We were planning on creating a base class that would handle the proxy step for listener management. When a listener would call addListener(this) to a job the it would get added to a listener list. If the requested queue is different than the thread that the notification would happen on then a proxy would be stored, otherwise it would just be the object. But that doesn't really work ( and now that I think of it doesn't even make much sense!!! ).
So I guess there are 2 options open to us:
1) When storing the listeners ALWAYS create a proxy since we never know if the threads will be different
or
2) When notifying the listeners, get a proxy object before making each call. This could be handled through an enumeration interface that just creates a container of proxied objects and hands it back.
And when I look at those two options, option one is WAY better. Consider that any one object might make multiple calls to update its status; To have to call getProxyForObject each time for the entire list of listeners ( could be one could be one hundred and one ) would whistle beef.
Well, that's our little headache and I think option 1 is the way to go. Let's look at the proxy stuff a little more before we go...
The proxy code actually creates a little linked list for each object that you request a proxy for. The root object of that list is linked to the nsISupports interface, each additional proxy in the chain represents a different interface on the object. When you do a QI on a proxied object it walks through the chain until it finds the internal proxy container that links to the specific object and interface requested. Took me a bit of poking around to figure that out but neat!
Then I thought 'Okay, I see how the QI works, but it just hands back a handle to the nsProxyEventObject object, how do the methods get called on the right thing', and that's when I found the CallMethod() override and the nsProxyObject class. The nsProxyEventObject overrides the CallMethod call so that it pushes the call to the wrapped nsProxyObject. It is in that object where the method gets posted to the right event queue. It also appears that it is because of the magic of XPTCall that this works. I read the docs over here and here by jband to get a little explanation but it sounds like some crazy business. I'll save an in depth study for XPTCall when I have a week of spare time on my hands.
But in short there is some low level code that builds call frames that allow any xpcom object to masquarade as any other (I think). The XPTCall code was desigend to allow just that case and the ability to call across threads. XPConnect uses it alot and the proxy stuff uses it too.
]]>
One of my favorite book series is the fantasy series by George R. R. Martin, A song of Ice and Fire. He's not afraid to do really nasty things (like kill or blind) to major characters and he's characters aren't as one dimensional as so many other fantasy books. You'll end up liking or respect the "bad guys" and finding the shallow points and dark sides of the "good guys". Certainly there are some characters who have a certain moral compass that puts them above so many others. All-in-all it is a fabulous series and I can't wait for the next book to come out.
