On Sun, Mar 23, 2008 at 10:22 PM, Mark Johnson <[EMAIL PROTECTED]> wrote: > > Vivien Malerba wrote: > > On Sun, Mar 23, 2008 at 4:41 PM, Mark Johnson <[EMAIL PROTECTED]> wrote: > > > >> Vivien Malerba wrote: > >> > On Sat, Mar 22, 2008 at 10:58 PM, Mark Johnson <[EMAIL PROTECTED]> > 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 _______________________________________________ gnome-db-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-db-list
