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

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

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?



- cee1

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]