Re: [gnome-db] 2 issues with GdaConnection

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?
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
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.

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.
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.

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.


Hopefully, this doesn't sound too much like I'm ranting about it. I intend it as constructive criticism.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]