On 31 Jul 2010, at 22:07, Axel Simon wrote: > On 31.07.2010, at 06:35, Hamish Mackenzie wrote: > >> 1 patch for repository http://code.haskell.org/gtk2hs: >> >> Sat Jul 31 16:16:07 NZST 2010 Hamish Mackenzie >> <hamish.k.macken...@googlemail.com> >> * Disable gdk thread locks in Win32 since "With the Win32 backend, GDK calls >> should not be attempted from multiple threads at all." and the locking calls >> conflict with ghci and template haskell. >> > > It is true that calls to Gdk should not be done from multiple threads. This > is exactly what that lock you're removing is for. It ensures that the GC if > ghc's runtime system (which calls finalizers from multiple threads) are > enqueued and then finalized from the main Gtk loop (which runs in the correct > thread if the Haskell program doesn't do anything weird).
So the queueing keeps the calls on one thread (the main loop thread) and if the user makes all there GDK calls on that thread too then the locks are redundant. But if someone calls GDK on another thread it will fail to acquire the GDK lock and fail gracefully. > I assume you're using the head of the repository. If there are still > concurrency problems in ghci, I'd like to know! Yes I was using head (and ghc 6.12.3). I have not seen concurrency issues, but I have not been looking for them. This is the issue I was trying to fix http://hackage.haskell.org/trac/gtk2hs/ticket/1197 I just tried and it looks like a better solution might be to switch from GTK_THREADS_ENTER/LEAVE to gtk_threads_enter/leave. Could we do this instead? Hamish ------------------------------------------------------------------------------ The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm _______________________________________________ Gtk2hs-devel mailing list Gtk2hs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel
