By passing NULL to `g_signal_new` instead of a marshaller, GLib will
actually internally optimize the signal (if the marshaller is available
in GLib itself) by also setting the valist marshaller. This makes the
signal emission a bit more performant than the regular marshalling,
which still needs to box into `GValue` and call libffi in case of a
generic marshaller.
Note that for custom marshallers, one would use
`g_signal_set_va_marshaller()` with the valist marshaller instead.
Between getting the GSource with the mutex and destroying it, something
else might've destroyed it already and we would have a dangling pointer.
Keep an additional reference just in case.
Signal watches are reference counted and gst_bus_remove_watch() would
immediately remove it, breaking the reference counting. Only
gst_bus_remove_signal_watch() should be used for removing signal
watches.
This is something bindings can't handle and it causes leaks. Instead
move the ref_sink() to the explicit, new() constructors.
This means that abstract classes, and anything that can have subclasses,
will have to do ref_sink() in their new() function now. Specifically
this affects GstClock and GstControlSource.
https://bugzilla.gnome.org/show_bug.cgi?id=743062
This is useful for integration with other event loops that work by
polling file descriptors. G_IO_IN will always be set whenever a message
is available currently.
https://bugzilla.gnome.org/show_bug.cgi?id=776126
Use g_object_new() instead which nowadays has a shortcut for the
no-properties check. It still does an extra GType check in the
function guard, but there's a pending patch to remove that
and it's hardly going to be a performance issue in practice,
even less so on a system that's compiled without run-time checks.
Alternative would be to move to the new g_object_new_properties()
with a fallback define for older glib versions, but it makes the
code look more unwieldy and doesn't seem worth it.
Fixes deprecation warnings when building against newer GLib versions.
https://bugzilla.gnome.org/show_bug.cgi?id=780903
It might happen that we popped the message before writing of the control
happened. In this case we just have to retry again a bit later, and failure to
do so will cause an additional byte in the control and the GSource /
gst_poll_wait() to always wake up again immediately.
https://bugzilla.gnome.org/show_bug.cgi?id=750397
When holding a regular ref it will cause the GstBus to never
reach 0 references and it won't be destroyed unless the application
explicitly calls gst_bus_remove_signal_watch().
Switching to weakref will allow the GstBus to be destroyed.
The application is still responsible for destroying the
GSource.
https://bugzilla.gnome.org/show_bug.cgi?id=762552
Shouldn't take the lock while unreferencing messages, because that may cause
more messages to be sent, which will try to take the lock and cause the app to
hang.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=728777
Async message delivery (where the posting thread gets blocked
until the message has been processed and/or freed) was pretty
much completely broken.
For one, don't use GMutex implementation details to check
whether a mutex has been initialized or not, esp. not
implementation details that don't hold true any more with
newer GLib versions where atomic ops and futexes are used
(spotted by Josep Torras). This led to async message
delivery no longer blocking with newer GLib versions on
Linux.
Secondly, after async delivery don't free mutex/GCond
embedded inside the just-freed message structure.
Use a new (private) mini object flag to signal GstMessage
that the message being freed is part of an async delivery
on the bus so that the dispose handler can keep the message
alive and the bus can free it once it's done cleaning up
stuff.
TRUE is 1, but every other non-zero value is also considered true. Comparing
for equality with TRUE would only consider 1 but not the others.
Also normalize booleans in a few places.
Don't rely on g_source_remove() because it operates on the main
context. If a signal watch was added to a new thread-default context
g_source_remove() would have no effect. So simply use
g_source_destroy() to avoid this problem.
Additionally the source_id was removed from GstBusPrivate because it
was redundant with the signal watch GSource also stored in that
structure.
https://bugzilla.gnome.org/show_bug.cgi?id=734716
Support for (nullable) was added to G-I at the same time as nullable
return values. Previous versions of G-I will not mark return values as
nullable, even when an (allow-none) annotation is present, so it is
not necessary to add (allow-none) annotations for compatibility with
older versions of G-I.
https://bugzilla.gnome.org/show_bug.cgi?id=730957
They are very confusing for people, and more often than not
also just not very accurate. Seeing 'last reviewed: 2005' in
your docs is not very confidence-inspiring. Let's just remove
those comments.
Clear the initial floating ref in the init function for
busses and clocks. These objects can be set on multiple
elements, so there's no clear parent-child relationship
here. Ideally we'd just not make them derive from
GInitiallyUnowned at all, but since we want to keep
using GstObject features for debugging, we'll just do
it like this.
This should also fix some problems with bindings, which
seem to get confused when they get floating refs from
non-constructor functions (or functions annotated to
have a 'transfer full' return type). This works now:
from gi.repository import GObject, Gst
GObject.threads_init()
Gst.init(None)
pipeline=Gst.Pipeline()
bus = pipeline.get_bus()
pipeline.set_state(Gst.State.NULL)
del pipeline;
https://bugzilla.gnome.org/show_bug.cgi?id=679286https://bugzilla.gnome.org/show_bug.cgi?id=657202
These changes are to clean up syntax issues such as missing colons,
missing spaces, etc., and minor issues such as argument names in
headers not matching the implementation and/or documentation.
