On Oct 23, 2010, at 20:41, Andy Stewart wrote: > I think this is have internal trick in GIO C code that will break if > we > use wrapNewGObject in fileEnumeratorNextFile > > But makeNewGObject always works, so let's keep makeNewGObject.
If makeNewGObject works and wrapNewGObject does not, then makeNewGObject is the correct one. makeNewGObject is used to wrap a handle that is not new. As far as I understand this is the picture: function refs held action refs held constructGObject f objectRefSink H makeGObject C objectRef C,H wrapGObject C none H The first "refs held" column indicates if C holds a floating reference (f) or a real reference (C). Then the "action" is performed on the object and afterwards the reference counts are held by Haskell "H", by the C object "C" or by both. wrapGObject does not do anything to the reference count, it simply takes the C reference count "C" and uses it from Haskell "H". All three functions will add an unrefGObject call as finalizers, so that the "H" reference is returned when the ForeignPtr is garbage-collected. So if something crashes because you've changed a "makeGObject" to a "wrapGObject" then it must be that "makeGObject" was needed since the C object expects that it still holds a reference to the object. I hope I got this right and that this clarifies things. Please tell me if this is inaccurate, I'd like to have the right intuition about this. Cheers, Axel ------------------------------------------------------------------------------ Nokia and AT&T present the 2010 Calling All Innovators-North America contest Create new apps & games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev _______________________________________________ Gtk2hs-devel mailing list Gtk2hs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel
