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.
Mark _______________________________________________ gnome-db-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-db-list
