Web lists-archives.com

Re: [Discuss] Make a thinner Glib/GTK+ to fit tiny device better

2015-10-17 3:29 GMT+08:00 Nicolas Dufresne <nicolas.dufresne@xxxxxxxxxxxxx>:
> Le samedi 17 octobre 2015 à 01:20 +0800, cee1 a écrit :
>> 2015-10-16 23:46 GMT+08:00 Florian Müllner <fmuellner@xxxxxxxxx>:
>> > On Fri, Oct 16, 2015 at 5:38 PM, cee1 <fykcee1@xxxxxxxxx> 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

BTW, I go through internal of gst_mini_object_make_writable, and
following logical seems confused:

    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


- cee1
gtk-devel-list mailing list