Re: [gnome-db] 2 issues with GdaConnection

["Vivien Malerba" <vmalerba gmail com>]

On Sun, Mar 23, 2008 at 10:22 PM, Mark Johnson <mrj001 shaw ca> wrote:
>
> Vivien Malerba wrote:
>  > 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
>  >
>  >
>  Thanks, I believe I understand it better now.

Great! Anyway, it shows that the doc is so important...

Cheers,

Vivien