On May 8, 2009, at 11:18, Colin McQuillan wrote: > For now I'm using the attached patch and Yi seems more stable. I just > idleAdd all finalizers. This approach has the drawback that glib > objects cannot be garbage collected until the main loop.
True, but right now, nothing is garbage collected until the Haskell run-time runs again. Thus, memory that is linked via a pointer that pass between Haskell and Gtk+ and then from Gtk+ to Haskell needs two GC to be deleted. > For example > someone using Cairo-SVG to produce images in the background would run > out of memory. Well, if it ran in the background, then presumably the OS thread running the Gtk+ main loop is still running and thus freeing memory. But I agree that releasing memory is now restricted to a single thread rather than all of the Haskell threads. Furthermore, if you'd use Cairo without Gtk+ you would never even run the Gtk+ main loop. > Gtk# takes the same approach, except it uses a queue: > http://anonsvn.mono-project.com/viewvc/trunk/gtk-sharp/glib/ > Object.cs?revision=133451&view=markup > Also, Gtk# Objects can be disposed manually, so apps do not have to > depend on the garbage collector. We could add a function to do that. > java-gnome has taken a more comprehensive approach to thread safety by > hooking into the GDK lock: > http://blogs.operationaldynamics.com/andrew/software/java-gnome/ > thread-safety-for-java.html Yes, we discussed that and thought that wrapping every call to Gtk would be too slow. But it seems that this isn't really an issue. The current Glib lock isn't reentrant, but we could replace the lock using one that is. We would then have to change the way we generate calls to Gtk+, probably by modifying c2hs. We could then also take this approach to run the finalizers, i.e., wrap the execution of finalizers with the thread_enter and thread_leave calls. This would stall the GC if the main loop were running. But maybe this acceptable. > <DRAFT-finalizer-threads.dpatch> Ah, ok, so this would be a starting point. You say it's *more* stable. Does it still crash? Axel. > ---------------------------------------------------------------------- > -------- > 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 ------------------------------------------------------------------------------ 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
