On 31.07.2010, at 14:38, Hamish Mackenzie wrote: > 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. >
Uh, your elaboration doesn't sound right. The code you're looking at only concerns the garbage collection (GC). The GC in ghc is multi-threaded and will execute the finalizers of GObjects from any thread it likes. If GObjects hold X11 or Win32 resources then these are freed in the finalizer which would thus happen from the wrong thread. Thus, we enqueue the calls to finalizers in a queue and empty this queue from the main loop when it runs the next time after the GC has run. This behaviour is totally independent of how the programmer users multi-threading in the application. The user should run initGUI and mainGUI from the thread that runs 'main'. All calls to Gtk should be made from this thread as well. Exceptions are mainLoopAddIdle and friends. These functions are also used in postGUISync and postGUIAsync. In particular, the library never "fails gracefully" if the user gets the concurrency wrong. >> 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? > This is a linking problem I tried to fix by using Window's mutexes on Windows. I might have broken that with the last fix. If the linking problem itself goes away by calling gtk_threads_enter instead of GTK_THREADS_ENTER then maybe we should do that throughout and get rid of the #ifdefs for Windows. So, it looks like the binary builds for Windows has done something weird to the macros. Cheers, Axel > 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
