In the last year working at Xamarin, I have learned lots of new things (.NET, Cocoa, …), and since the beginning of that, I was thinking on bringing some of that nice stuff to GNOME, but didn’t really had the chance to finish anything. But, fortunately, being free now (on vacation), I finally finished the 1st thing: GObservableCollection, a thread-safe collection implementation which emits signals on changes.
It is based on ideas from .NET’s ObservableCollection and concurrent collections, which I’ve used successfully for building a multi-thread data processing app (with one thread updating the collection and another consuming it), so I thought it would be a good addition to GLib’s API. This class can be used on single-threaded apps to easily get notifications for changes in a collection, and in multi-threaded ones for, as mentioned above, easily share data between different threads (as can be seen on the simple test I wrote).
This is the 1st working version, so for sure it will need improvements, but instead of keeping it private for a few more months, I thought it would be better getting some feedback before I submit it as a patch for GLib’s GIO (if that’s the best place for it, which I guess it is).
Just some unsolicited thoughts.
I think if we are to go down this route, we should probably make an interfiace for this. There are lots of places where I’d like to see item-added/removed signals. My understanding is that Collection in .NET is the interface?
If that is the case, I believe that the underlying implementation is not critical. But it would determine whether or not a signal like “inserted” would be available.
Initially, I would prefer something not G(S)List backed, simply of scalability issues. If we went the interface route, we could have a couple implementations. A GPtrArray backed implemention (similar to ArrayList? in .NET) comes to mind. Also, a GSequence backed collection.
And by scalability issues, I don’t mean millions of items, just avoiding turning some O(log n) problems into O(n^2) problems.
What about a GHashTable backed collection? I am actually using something like that in my applications.
I might be biased but I haven’t seen any GObject collections in glib. There are in libgee and adding a wrapper class should not be a problem (as added bonus the mutex could be removed and ConcurrentList be used instead).
Doesn’t look threadsafe to me. For instance:
g_signal_emit (collection, signals[ITEM_ADDED], 0, item, g_slist_length (collection->priv->items) – 1);
Accesses the list without holding the lock.
Also, what are the exact semantics wrt item lifetimes here? This code passes a pointer to item during the signal handler but has no explicit ref to it. Can’t it in parallel also be removed from the collection and then freed?
You’re also emitting signals on essentially random threads. This is not wrong per-se, but it can be very complex to handle correctly on the called side.
Also, basing the storage on GSList, but having an index-based accessor screams for accidental O(n^2) algorithms.
Nice work Rodrigo!
I think that moving to others frameworks and platforms, like .Net, Cocoa, Android, the JavaScript world (Bootstrap, jQuery, …) etc, helps a loot to improve the development skills and to detect the gaps in GNOME, as you point.
Just an idea about the GObservableCollection, now uses a GSList to store the data. What do you think to turn GObservableCollection into an interface allowing multiple implementations with differents kinds of stores?
What about a GHashTable backed collection? I am actually using something like that in my applications.
And by scalability issues, I don’t mean millions of items, just avoiding turning some O(log n) problems into O(n^2) problems.