Question on reference handling of GstEvents

[José Alburquerque-3]

Hi.  I posted a few days ago asking a question on the GstBus "watch"
functions because I'm actively working on C++ bindings for GStreamer.  
Right now I'm working on the GstEvent classes and I have another general
question:  As I understand it, the gst_element_send_event() function
takes "ownership" of the GstEvent and, as the docs say, it is necessary
to "reference" it if a copy of the GstEvent is wanted.  My question is:  
In general, do all functions taking GstEvents take "ownership" of
GstEvents this way?  The only real function I have found that accepts a
GstEvent is the one I just mentioned.  Are there others?  I'm trying to
decide how to handle the referencing of GstEvents in the bindings so I'm
trying to get a sense of what happens with GstEvents.  Any help will be
greatly appreciated.  Thanks.

-Jose

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Tim-Philipp Müller-2]

On Wed, 2008-01-02 at 22:33 -0500, José Alburquerque wrote:

Hi Jose,

> As I understand it, the gst_element_send_event() function
> takes "ownership" of the GstEvent and, as the docs say, it is necessary
> to "reference" it if a copy of the GstEvent is wanted.  My question is:  
> In general, do all functions taking GstEvents take "ownership" of
> GstEvents this way?

No, see e.g. gst_event_parse_*().

>   The only real function I have found that accepts a
> GstEvent is the one I just mentioned.  Are there others?

Yes, e.g. gst_pad_{push|send}_event(), gst_pad_event_default().

> I'm trying to decide how to handle the referencing of GstEvents in the
>  bindings so I'm trying to get a sense of what happens with GstEvents.
>  Any help will be greatly appreciated.

Generally, all functions that push or send events or buffers to another
pad or an element take ownership of that event or buffer.  Others do
usually not (with exceptions such as gst_adapter_push()).  This only
applies to events and buffers, but not for example queries, where the
called function never takes ownership (IIRC).

Cheers
 -Tim



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Edward Hervey]

Hi,

On Thu, 2008-01-03 at 09:53 +0000, Tim Müller wrote:

> On Wed, 2008-01-02 at 22:33 -0500, José Alburquerque wrote:
>
> Hi Jose,
>
> > As I understand it, the gst_element_send_event() function
> > takes "ownership" of the GstEvent and, as the docs say, it is necessary
> > to "reference" it if a copy of the GstEvent is wanted.  My question is:  
> > In general, do all functions taking GstEvents take "ownership" of
> > GstEvents this way?
>
> No, see e.g. gst_event_parse_*().
>
> >   The only real function I have found that accepts a
> > GstEvent is the one I just mentioned.  Are there others?
>
> Yes, e.g. gst_pad_{push|send}_event(), gst_pad_event_default().
>
> > I'm trying to decide how to handle the referencing of GstEvents in the
> >  bindings so I'm trying to get a sense of what happens with GstEvents.
> >  Any help will be greatly appreciated.
>
> Generally, all functions that push or send events or buffers to another
> pad or an element take ownership of that event or buffer.  Others do
> usually not (with exceptions such as gst_adapter_push()).  This only
> applies to events and buffers, but not for example queries, where the
> called function never takes ownership (IIRC).

  We had to do the same special handling with gst-python. If you look at
gst-python/gst/*.defs you can see which parameters of which functions
need to be handled like that (grep for "(keep-refcount)").

  The way it's done in the python bindings is that we keep a refcount on
GStreamer objects for as long as there's a corresponding python object.
  So in the specials cases above, we INCREMENT the refcount of the
argument before calling the given method. This means that after the
function returns we guarantee that our python object still has a
reference on the object (which will be dropped when python no longer
uses that object).

  Hope this helps.

    Edward

>
> Cheers
>  -Tim
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[José Alburquerque-3]

Edward Hervey wrote:

> Hi,
>
> On Thu, 2008-01-03 at 09:53 +0000, Tim Müller wrote:
>  
>> On Wed, 2008-01-02 at 22:33 -0500, José Alburquerque wrote:
>>> I'm trying to decide how to handle the referencing of GstEvents in the
>>>  bindings so I'm trying to get a sense of what happens with GstEvents.
>>>  Any help will be greatly appreciated.
>>>      
>> Generally, all functions that push or send events or buffers to another
>> pad or an element take ownership of that event or buffer.  Others do
>> usually not (with exceptions such as gst_adapter_push()).  This only
>> applies to events and buffers, but not for example queries, where the
>> called function never takes ownership (IIRC).
>>    
>
>   We had to do the same special handling with gst-python. If you look at
> gst-python/gst/*.defs you can see which parameters of which functions
> need to be handled like that (grep for "(keep-refcount)").
>
>   The way it's done in the python bindings is that we keep a refcount on
> GStreamer objects for as long as there's a corresponding python object.
>   So in the specials cases above, we INCREMENT the refcount of the
> argument before calling the given method. This means that after the
> function returns we guarantee that our python object still has a
> reference on the object (which will be dropped when python no longer
> uses that object).
>
>   Hope this helps.
>
>     Edward
>
>  

It does, thanks.  From what Tim says it sounds as if keeping a refcount
depends on which method (function) operates (is called) on the object
(GstEvent).  I'm thinking of keeping a refcount of the object just
before the "owner taking methods" are called.  Thanks so much for your
answers.

-Jose

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel