Most of the stuff on YouTube is lame, but every now and then I find or get sent something BRILLIANT!!! Like this video mashup of Star Wars and Monty Python

Hey, that's neat. I was going to write a short blurb about how I had come home and wanted some mellow music but not super mellow and had seen Sheryl Crow in my collection and missed the copy of her first album I lost. I then hopped on Yahoo Music and found it and realized how much I really like this album.

Then I went to write the post and realized it was actually Tuesday!!! Co-incidence? I don't think so. So I think I'm going to write a blog post on Tuesdays and call it my Tuesday Night Music Club. Maybe I'll even link to some music. ( I hope Sheryl Crow doesn't mind ).

On a side-note, I watched the show Heroes last night (re-run) for the first time and found it intriguing enough to add to my dvr. Felt like something Fox would have aired, just with the kind-of glamoury feel to it and the young cast. But then Lost feels a lot like that too (although I haven't watched that one since the first season). And kudos to NBC for providing EVERY Heroes episode online. Too bad my home internet connection blows chunks.

I think I'm going to try and follow a pattern for music links. I'll have to always have some Van Halen, or Aerosmith, and then something from a musical or movie soundtrack. After those two I think I'll try for something a little off beat, not that much of my music is very off-beat, and then just something else relevant.

So here's the selection for the first post.

Soak up the Sun from Sheryl Crow's C'mon C'mon album. Sadly I don't have Tuesday Night Music Club in my collection and I'm not about to post music I don't own.
Could this be love, a lesser known track from Van Halen's Women and Children First album. ( Sail away with someones daughter... ) This one's for you Dave.
Cool, from West Side Story, maybe the greatest musical EVER ( it _is_ based on Shakespeare afterall)
And finally from Presidents of the United States of America, Nake and Famous. Some of my favorite lyrics come from their debut album. "Those lucky suckers, they don't have to work, make 3D billboards and big 30 ft. Smurfs."

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.