2015-10-17 3:29 GMT+08:00 Nicolas Dufresne <nicolas.dufre...@collabora.com>: > Le samedi 17 octobre 2015 à 01:20 +0800, cee1 a écrit : >> 2015-10-16 23:46 GMT+08:00 Florian Müllner <fmuell...@gnome.org>: >> > On Fri, Oct 16, 2015 at 5:38 PM, cee1 <fykc...@gmail.com> wrote: >> >> If yes, we may let GObject inherit from >> >> GstMiniObject to obtain the COW feature? >> > >> > This would break ABI, so not something you should expect any time >> soon. >> >> So what about GObject2(a bit likes playbin2 in GStreamer)? Code can >> change to inherit from it and recompiling... > > That's an extremely ugly fallback solution, specially for a feature > that no one will use. > > The problem here is that GObject cannot be copied generically, when > they are, it's a custom feature. Note that reference based locking > isn't always great. If I was to redo that, I'm opt for explicit locking > instead. In GStreamer we have hit many of the limitation of this model. > This can of course be introduced with an GInterface if you drop this cr > azy idea of using ref-count to figure-out writability. > Is there any examples about the limitation of this reference count based model at hand?
So can I say gstreamer use COW mainly for locking(similar to RCU), not for the purpose of removing duplication? For comparison, IIUIC, EFL implements a GSlice (some what)equivalent layer[1], but provides COW-able memory objects. It will even find memory objects which have the same content and merge them in idle, according to the article https://phab.enlightenment.org/phame/live/1/post/efl_memory_consumption_moo/. BTW, I go through internal of gst_mini_object_make_writable, and following logical seems confused: """ http://cgit.freedesktop.org/gstreamer/gstreamer/tree/gst/gstminiobject.c#n190 gst_mini_object_lock() ... if (access_mode & GST_LOCK_FLAG_EXCLUSIVE) { /* shared ref */ newstate += SHARE_ONE; access_mode &= ~GST_LOCK_FLAG_EXCLUSIVE; } """ Why under an EXCLUSIVE mode, a mini object can be shared? --- 1. https://docs.enlightenment.org/stable/efl/group__Eina__Cow__Group.html Regards, - cee1 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
