Hi. I have a question on the mutability enforcement ability of a
GstStructure. As I understand it, the structure is owned by a parent with refcounting capabilities. The docs say that the structure can make itself mutable (?) by using the gst_structure_set_parent_refcount() method, which seems to simply augment the parent's refcount. I'm wondering: Suppose that the parent is refcounted more than once by other means, would this also make the structure immutable? Is this desired/intentional behavior for GstStructure? Is a GstStructure supposed to be immutable if its parent is refcounted more than once even if the gst_structure_set_parent_refcount() method is not used? Thanks. -Jose ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
On Fri 18 Jan 2008 00:24, José Alburquerque <[hidden email]> writes:
> Hi. I have a question on the mutability enforcement ability of a > GstStructure. Check gstreamer/docs/design/part-MT-refcounting.txt, "Mutable substructures". Andy -- http://wingolog.org/ ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Andy Wingo wrote:
> On Fri 18 Jan 2008 00:24, José Alburquerque <[hidden email]> writes: > > >> Hi. I have a question on the mutability enforcement ability of a >> GstStructure. >> > > Check gstreamer/docs/design/part-MT-refcounting.txt, "Mutable > substructures". > > Andy > In the mean time, my real question may not be directly answered there because my question is a bit more general. I'm a bit curious as to why the GstStructure immutability is related to the parent's ref count and not to some other criteria. Is the ref count the best way to implement immutability? Is the ref count used because, by design, a GstStructure *cannot* be modified when its parent is referenced more than once or could it be possible to reference the parent more than once and still modify the GstStructure? In trying to provide C++ bindings, I'm encountering a few difficulties with GstStructure immutability because in C++, inadvertently, an object such as a GstCaps may be referenced more than once by a simple C++ statement (by our design, of course) such as: caps->set_simple("field1", value1)->set_simple("field2", value2)->set_simple("field3", val3); In our bindings, the set_simple() method of the Gst::Caps class returns a "Reference Pointer" (RefPtr) to the Caps. (A "Reference Pointer" is a class that "wraps" other classes, automatically referencing them and unreferencing them when the class goes out of scope.) We want this feature to make referencing and unreferencing of objects automatic, but the multiple references caused in this situation (and others similar to this one that I can describe) makes the GstStructure of the caps immutable before all the "setting" can be completed. Can someone see our predicament? Thanks. -Jose ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
On Sun, Feb 10, 2008 at 09:41:20AM -0500, José Alburquerque wrote:
> In trying to provide C++ bindings, I'm encountering a few difficulties > with GstStructure immutability because in C++, inadvertently, an object > such as a GstCaps may be referenced more than once by a simple C++ > statement (by our design, of course) such as: > > caps->set_simple("field1", value1)->set_simple("field2", > value2)->set_simple("field3", val3); Could you come up with a better example? You've changed the return value of set_simple, which seems like a dangerous path to follow for a language wrapper. dave... ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
David Schleef wrote:
> On Sun, Feb 10, 2008 at 09:41:20AM -0500, José Alburquerque wrote: > >> In trying to provide C++ bindings, I'm encountering a few difficulties >> with GstStructure immutability because in C++, inadvertently, an object >> such as a GstCaps may be referenced more than once by a simple C++ >> statement (by our design, of course) such as: >> >> caps->set_simple("field1", value1)->set_simple("field2", >> value2)->set_simple("field3", val3); >> > > Could you come up with a better example? You've changed the return > value of set_simple, which seems like a dangerous path to follow for > a language wrapper. > > > > dave... > > > (which wraps objects and automatically increments/decrements their references) and when it is "cast" (see this bug report I filed hoping for some possible solution: http://bugzilla.gnome.org/show_bug.cgi?id=510301). The reason we want to design our Caps::set_simple() method to return a "pointer" (in fact it is our RefPtr wrapper class) to the caps is to allow the "chain of sets" you see above. Your gst_caps_set_simple() returns void, so I don't really see where the danger would be. There is a difference, of course, and that would be in the usage syntax. We're debating whether to use this format or something else, but right now, we would really like to use it because due to our effort to be type safe, we are not implementing methods with variable arguments and this would make it easier for developers to "set" a series of values in GstStructure fields of the GstCaps (in C++). -Jose ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
On Mon, Feb 11, 2008 at 04:07:14PM -0500, José Alburquerque wrote:
> A better example would be what happens with our RefPtr wrapper class (which > wraps objects and automatically increments/decrements their references) and > when it is "cast" (see this bug report I filed hoping for some possible > solution: http://bugzilla.gnome.org/show_bug.cgi?id=510301). One possible workaround for this is to add a wrapper_refcount field that is only used for language wrappers. Language wrappers would increment the wrapper_refcount field to indicate that the refcount is due to the bindings only, and not to be used as in determining writablity. (This is only a suggestion. Don't know if it would work, or even wise. Definitely something we need to address in 0.11. Actually, we needed to address it in 0.7, but it got dropped because of more pressing issues.) > The reason we want to design our Caps::set_simple() method to return a > "pointer" (in fact it is our RefPtr wrapper class) to the caps is to allow > the "chain of sets" you see above. Your gst_caps_set_simple() returns > void, so I don't really see where the danger would be. The obvious danger is that you waste application developers' time. Based on my observation of new developers in the past, the thought process would go something like this: - Hmm, Caps::set_simple() returns Caps, but the C version doesn't. - I wonder if the C documentation is correct for the C++ function. - I wonder if the C++ function is supposed to work like gst_caps_make_writable(), and I'm supposed to assign it to my local variable. - (looks in the C++ documentation, finds nothing, becuase "it's obvious") - (asks on IRC, gets no conclusive answer) - *frustration* Gratuitous differences are completely wasteful, since they require extra documentation, extra neurons to remember the differences, and extra bugs because people don't remember (or never knew) the differences. However, if a C function completely goes against language style, feel free to change it. The python bindings do this quite frequently, because otherwise the combination of gstreamer+python would feel like writing C with python syntax. This is not such a case. Also, set_simple is variadic for a reason. Setting a single caps field may take multiple values, for example, when setting fractions. dave... ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
David Schleef wrote:
> On Mon, Feb 11, 2008 at 04:07:14PM -0500, José Alburquerque wrote: > >> A better example would be what happens with our RefPtr wrapper class (which >> wraps objects and automatically increments/decrements their references) and >> when it is "cast" (see this bug report I filed hoping for some possible >> solution: http://bugzilla.gnome.org/show_bug.cgi?id=510301). >> > > One possible workaround for this is to add a wrapper_refcount field > that is only used for language wrappers. Language wrappers would > increment the wrapper_refcount field to indicate that the refcount > is due to the bindings only, and not to be used as in determining > writablity. (This is only a suggestion. Don't know if it would > work, or even wise. Definitely something we need to address in 0.11. > Actually, we needed to address it in 0.7, but it got dropped because > of more pressing issues.) > > >> The reason we want to design our Caps::set_simple() method to return a >> "pointer" (in fact it is our RefPtr wrapper class) to the caps is to allow >> the "chain of sets" you see above. Your gst_caps_set_simple() returns >> void, so I don't really see where the danger would be. >> > > The obvious danger is that you waste application developers' time. > Based on my observation of new developers in the past, the thought > process would go something like this: > > - Hmm, Caps::set_simple() returns Caps, but the C version doesn't. > - I wonder if the C documentation is correct for the C++ function. > - I wonder if the C++ function is supposed to work like > gst_caps_make_writable(), and I'm supposed to assign it to my > local variable. > - (looks in the C++ documentation, finds nothing, becuase "it's obvious") > - (asks on IRC, gets no conclusive answer) > - *frustration* > > Gratuitous differences are completely wasteful, since they require > extra documentation, extra neurons to remember the differences, and > extra bugs because people don't remember (or never knew) the differences. > > However, if a C function completely goes against language style, feel > free to change it. The python bindings do this quite frequently, > because otherwise the combination of gstreamer+python would feel like > writing C with python syntax. This is not such a case. > > will be using this method and be assured that it is not for gratuitous purposes. I understand that this case seems as if there should be no difference between the C and C++ style, but if we will not be using the variable argument style methods, I thought that such an addition would be sort of useful. When I began working in the (already begun) wrapping process, I noticed that something similar was used for linking elements (e.g. element->link(element2)->link(element3)) and I thought that this same method could be used in this Caps case, but it hasn't been in this case. I really want to apologize for bringing up this request, I'm sure it's coming from a newcomer at this point so please forgive me because I probably haven't considered everything and shouldn't be making request that I don't even understand. I wish you well in your continued development of this excellent software. I'm sure a solution will present itself in the future at some point. Please forgive my inconveniencing you. Thanks for your response. -Jose > Also, set_simple is variadic for a reason. Setting a single caps field > may take multiple values, for example, when setting fractions. > > > > dave... > > > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Free forum by Nabble | Edit this page |