Quick summary: The sbIMediaListEnumerationListener interface has changed. Click here for the diff and keep reading for the backstory.

A few weeks ago one of our developers was having difficulty implementing the sbIMediaListEnumerationListener interface in JavaScript — it just didn’t seem to work! Check out the original IDL for this interface then have a look at the implementation code:

var updateListener = {
  onEnumerationBegin: function() {
  },
  onEnumeratedItem: function(list, item) {
    item.setProperty(SBProperties.albumArtURL, albumPath);
  },
  onEnumerationEnd: function() {
  }
};
list.enumerateAllItems(updateListener);

Can you spot the problem? The original design of this interface defined both the onEnumerationBegin and onEnumeratedItem methods with a boolean return value that specified if the enumeration should continue. You would return true to continue or false to stop. The mistake here was not returning any value at all, which implicitly returns “undefined” to the caller. This value gets casted to a boolean false, meaning the enumeration should not continue. Whoops!

The fix here is simply to add “return true;” to the two methods. However, we felt that if even our own developers are tripping over this interface, we might want to rethink it a bit. Since continuing the enumeration is the most common case, we wanted to make it simple to do just that.

So bug 6388 was filed and the fix went in today. (See the new version here) We changed the return values of the two methods to integers and now have constants (sbIMediaListEnumerationListener.CONTINUE and sbIMediaListEnumerationListener.CANCEL) to use for the return values. This makes it very easy to tell what the code is doing rather than have to remember what returning true or false actually means.

Also, by making the CONTINUE constant equal to zero, implementations in JavaScript may omit the return statement entirely and the enumeration will continue. This should make it a lot harder for us lazy developers to shoot ourselves in the collective foot.

Has anyone else experienced any rough edges in our interfaces? If so, please let us know!

While working out some threading issues with our GStreamer core, I spent some time on #developers getting answers to some XPCOM threading questions I’ve had for a long time.

The first question was about when to use NS_IMPL_ISUPPORTS versus NS_IMPL_THREADSAFE_ISUPPORTS when implementing XPCOM components in C++. The difference is in the way the reference counting methods are implemented — the former manages the reference count in a non-thread safe way, and the latter manages it in a thread safe way. Additionally, when running a debug build, components that use NS_IMPL_ISUPPORTS will assert if they are AddRefed/Released by any thread other than the owning thread (the thread the component was created on).

Therefore, you should be using NS_IMPL_THREADSAFE_ISUPPORTS if your component will be reference counted on more than one thread. If this will never happen, you should use NS_IMPL_ISUPPORTS to avoid the additional overhead of thread safe reference counting.

Note that using NS_IMPL_THREADSAFE_ISUPPORTS in your component implementation does not relate to the thread saftey of the component’s implementation, just the reference counting methods. If you wish to declare the fact that your component is implemented in a thread safe way, you must implement nsIClassInfo and set the nsIClassInfo::THREADSAFE bit in your GetFlags implementation.

By setting the nsIClassInfo::THREADSAFE bit, you are ensuring the users of your component that your component’s implementation is thread safe, meaning there is no sequence of operations involving multiple threads that will put your component into an invalid state, observe the component to be in an invalid state, or violate any of the class’s invariants, preconditions, or postconditions (this definition of thread safety is adapted from IBM DeveloperWorks’ Java theory and practice: Characterizing thread safety).

As the implementor, not only must your make sure your implementation is thread safe, but the XPCOM components you collaborate with must also be thread safe. This is why a component that touches the DOM can never be declared as thread safe unless the access to the DOM is done through a proxy.

Thanks to brendan and shaver on #developers for taking the time to clear this up for me!