Re: [gnome-db] 2 issues with GdaConnection

["Vivien Malerba" <vmalerba gmail com>]

On Sun, Mar 23, 2008 at 4:41 PM, Mark Johnson <mrj001 shaw ca> wrote:
>
> Vivien Malerba wrote:
>  > On Sat, Mar 22, 2008 at 10:58 PM, Mark Johnson <mrj001 shaw ca> wrote:
>  >
>  >> Vivien Malerba wrote:
>  >>  >>  >
>  >>  >>  I don't think I have 2 references to the connection.  I've attached a
>  >>  >>  current snapshot of my file to let you see it.  It's a work in progress
>  >>  >>  for a test case for one of my bugs.
>  >>  >>
>  >>  >
>  >>  > The problem comes from the fact that when you call
>  >>  > g_object_unref(pConn), there is still an object holding a reference on
>  >>  > the pConn object, it is the GdaDataModel returned from the
>  >>  > gda_connection_statement_execute_select() function (which you ignore
>  >>  > in your example but still exists). Here is attached your example,
>  >>  > modified to show the reference count on the pConn object.
>  >>  >
>  >>  > Cheers,
>  >>  >
>  >>  > Vivien
>  >>  >
>  >>  Thanks, that fixed it.  The g_object_unref now does close the
>  >>  connection, so no unexpected EOF in the PostgreSQL log.
>  >>
>  >>  This is something I find difficult in glib/gnome programming in general
>  >>  - how to know when something needs to be unref'ed, and when something
>  >>  else might be keeping a reference to your object.  For example, nothing
>  >>  in the gda_connection_statement_execute or
>  >>  gda_connection_statement_execute_select documentation indicates that the
>  >>  connection reference count will be incremented.  The GdaDataModel page
>  >>  does not even contain the word connection.
>  >>
>  >
>  > The idea is that for any function which creates a new object, then you
>  > need to call g_object_unref() on the object,
>  This much is obvious.
>
> >  otherwise you must
>  > consider that the returned object is valid only within your function
>  > body (and if you wat to keep it, call g_object_ref() and
>  > g_object_unref() when done with it).
>  >
>  Wouldn't this cause a memory leak?  Wouldn't I have to destroy the
>  object by calling g_object_unref on it?

I would summarize things as:
for any object where the documentation does not say it creates a new object:
* if you need to keep a pointer to an object, then call
g_object_ref(object), and call g_object_unref(object) when you don't
need it anymore
* if you don't want to keep a reference on it, then you must assume
that the object can disappear without your knowledge (this is why I
say that the object should be considered valid only within your code
block).

for any object where the doc says a new object is created, then you
should assume you own the object, and just need to call
g_object_unref() when not needed anymore.

However you should never assume that you are the only one holding a
reference to an object (which is never assume that calling
g_object_unref() will destroy the object).

>
> > The reason the GdaDataModel keeps a reference on the connection is
>  > that some implementations need to execute some queries when they are
>  > used (like for cursor based access and for the soon-to-come dete model
>  > modification).
>  >
>  This makes sense, but is not documented.  I had wrongly assumed that the
>  connection was only needed for the duration of that function's execution.

This behaviour does not need to be documented (well, it could but just
for information as it should not change
the way the object is used).

>
>  My complaint is that I can't tell from a function's prototype whether it
>  needs the object only for the duration of that function's execution, or
>  if the object needs to keep a reference to my passed-in object.
>

If it needs the object for a longer time than just the duration of the
function, then it will itself call g_object_ref(). You don't need to
care.

> > Don't hesitate to signal any part of the doc you find misleading or
>  > unclear about that point.
>  >
>  Any function that changes a reference count should be documented as
>  doing so.

No need to, and it could also lead to some programming practices which
break what I explained a few lines above.

>
>  Here's another example of my complaint from the gobject documentation
>  (gobject/ch02.html) regarding g_value_copy:
>  "...the exact semantic of the copy calls is undefined since they depend
>  on the implementation of the copy function. Certain copy functions might
>  decide to allocate a new chunk of memory and then to copy the data from
>  the source to the destination. Others might want to simply increment the
>  reference count of the instance and copy the reference to the new GValue."
>
>  Each object defines its own copy semantics.  Fair enough.  The onus is
>  now on each object to document its copy semantics.  They don't (for
>  anything I've looked at; not just libgda).  This makes writing non-leaky
>  code much more difficult.

Yes, I agree that one is a bit difficult (I read the code myself to
see how things worked) and the semantics should be better documented,
but this is a corner case. The same could be said about the properties
(g_object_set(), g_object_get()).

Cheers,

Vivien