[Bug 736896] [REGRESSION] pygobject 3.13 now copies the GstStructure when getting them from a GstCaps, making it impossible to properly modify structures from caps in place.

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=736896

--- Comment #27 from Nicolas Dufresne (stormer) <nicolas.dufresne at collabora.co.uk> ---
As it is right now we can crash the interpretor too easily. Crashing the
interpreter is a big fault for a binding. I have strong opinion about never
letting this happen:

  buf = get_buf()
  buf.mini_object.unref()
  buf.anything -> possible crash

For this reason, ref/unref() method will be removed in 1.6 from GI even if this
is an API break. If you think this must come back, box the GstMiniObject, then
you can un-skip (normally the ref/unref annotation should cause ref/uner to be
hidden to users anyway, but you need a boxed type to add this annotation). It
make no sense to expose this. The binding must handle that, internally or live
without. I am definitive on that.

In the past, GI was simply doing nothing with (transfer-none) returned object.
So you could have:

  buf = object.get_buf() #transfer none
  object = somethingelse;
  buf.blabla # random crash

Where I think we have side effects, is that GST has this incompatible
writability based on ref-counting. This is not how ref-counting was suppose to
work in the GI design. GI idea to solve this wasn't bad, it's the simplest and
the most correct way to solve the previous crash.

  buf = object.get_buf() #transfer none
  # here, if the the boxed type has a reference, take a ref, otherwise call
  # the copy function. Anything not boxed must from now on be skipped or boxed.

And then it's all safe in the interpreter, but breaks with GStreamer
writability scheme. Causing the regression mention here (and making anything in
the GstMiniObject world that need writability to work to not work anymore).
IMHO, this ref bound writability was a bad idea, makes everything complex.
Explicit locking (like for GstMemory) would have done the job. But we can't
change it. If we want to support that, without overrides, we'll need to fix it
at the interpreter level. Imho, there can be some gain at not copying boxed
types received using (transfer none). It would enable more API, as in C, the
side effect of modifying a (transfer none) is to be expected. Now, the binding
level fix is quite simple for python. This is just pseudo solution, as we will
want to protect the private member more then what python interpreter do.

  buf = object.get_buf() # transfer none
    # Internally
    buf.__owner_object = object
  # The rest is safe, when we leave the scope/context (assuming we know
  # in the bindings)
    buf.__owner_object = none;

*IF* we can know that buf go out of scope (or context go away / last ref) then
we can manually break the circular dependency and prevent having to wait for
the GC. Though in fact, pure GC base languages (unlike python) don't offer you
this. For that, the automatic binding would need to add explicit destroy() or
dispose() (whatever convention is recommended for native types).

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.