On Mon, 2009-05-11 at 16:09 +0100, Colin McQuillan wrote: > Valgrind needs "--smc-check=all". So my original patch wasn't causing the > crash. > > Attached is my proposed patch. I've gone for C finalizers because it's > much simpler.
I'm currently trying to automatically wrap every call above Cairo,Pango,Glib in gdk_threads_enter and gdk_threads_leave just like the guy doing the Java binding proposed. In particular, every finalizer will try to acquire the lock before it calls the actual finalizer in Gtk +. This will fix the concurrency problem that manifests itself in the Xlib protocol error. If this works, then queueing finalizers won't strictly be necessary. However, it might be a good idea for performance: if the lock is taken when a finalizer is run, we simply call g_idle_add to run it and return to the GC immediately. So, I'll use your C functions to implement that. I think we've already discussed that finalization using an idle handler is a really bad idea when the gtk_main function isn't run on a regular basis: This is in particular true when somebody only uses the Cairo part to, say, generate some PDF files and doesn't bother about the GUI part at all. In this case nothing is ever freed. In the long run, I'd like to understand how the GC can enqueue a finalizer into the Haskell runtime but at the same time is unable to deal with callbacks triggered by the finalizers which do nothing else but enqueue a closure into the run-time. I wonder if this restriction can be lifted somehow. Then we could run the finalizers directly from the GC without worrying about the occasional one calling back to Haskell. Cheers, Axel. > Mon May 11 16:04:20 BST 2009 m.ni...@gmail.com > * Do finalizers in main thread > > g_object_unref should only be called in the main thread. See > > http://library.gnome.org/devel/gdk/unstable/gdk-Threads.html#gdk-Threads.description > > Even in single-threaded apps this is a problem. For example, in > Leksah, signals > on a TreeViewColumn get called when unused TreeViewColumns are finalized. > Finalizers can be called at any time, but, in general, callbacks might need > to > update the state of the application. Queuing unrefs avoids this > complication. > > There are three uses: GObject, GtkObject and G.U.G.Cairo. In all cases these > unrefs should be queued instead. > > We could do this in Haskell - GHC's Foreign.Concurrent allows Haskell > finalizers. But it is much neater to use purely C finalizers. ------------------------------------------------------------------------------ The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com _______________________________________________ Gtk2hs-devel mailing list Gtk2hs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel
