GNOME Bugzilla – Bug 679081
establishing parent-child relation not consistent with design docs
Last modified: 2014-04-10 07:00:16 UTC
There is description of establishing parent-child relation in the design documentation: http://cgit.freedesktop.org/gstreamer/gstreamer/tree/docs/design/part-relations.txt It is stated here, that set_parent() is called on child WITHOUT lock on the parent. However such establishment in gstreamer code (e.g. gstelement.c:gst_element_add_pad(), gstbin.c:gst_bin_add_func()) calls set_parent() with lock on the parent. In 0.10.36 gst_object_set_parent() called signal "PARENT_SET" which could call deadlock if this signal tried to lock the parent. In 0.11.92 signal calling is commented out and denoted "FIXME". Why not just make code consistent with design doc and call set_parent() on child without lock on the parent?
Wim?
The design docs lists the absolute minimal requirements to implement the parent-child relationship. Implementations can choose to use whatever locking they want around the set_parent() call as long as the defined locking order is preserved. What is the problem here?
The problem is, if we try to lock parent in "PARENT_SET" signal handler, a deadlock occurs.
For what it's worth, in 1.0 there's no more "parent-set" signal, and no "notify::parent" either, presumably for that exact same reason: /* FIXME, this does not work, the deep notify takes the lock from the parent * object and deadlocks when the parent holds its lock when calling this * function (like _element_add_pad()) */ /* g_object_notify_by_pspec ((GObject *)object, properties[PROP_PARENT]); */
Shall we close this bug then if it's no longer valid in 1.x ?