On 1 Aug 2010, at 02:01, Axel Simon wrote: > 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.
The point I was trying to make (badly) was that if initGUI and mainGUI are run in the same thread. Then gtk2hs_threads_initialise and gtk2hs_run_finalizers should always run in the same thread too. If so what are the calls to gdk_threads_enter/leave in these functions for? Some other thread? As far as I can see unless the user does something wrong... * calling initGUI and mainGUI on a different thread * calling another gtk2hs function that requires the lock on another thread I can't see that locking GDK in gtk2hs_threads_initialise and gtk2hs_run_finalizers will have any measurable effect. So I presumed it was added stop bad code running before it goes off causing weird thread synchronisation problems that are a pain in the ass to track down. Though it would be nicer if there was a way to actually raise an error rather than have it hang the bad threads (perhaps we could do that with gdk_threads_set_lock_functions). > 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. I have replaced references to GDK_THREADS_ENTER with gdk_threads_enter in the patch I sent earlier. The GDK docs seem to indicate that this is probably the right thing to do... http://library.gnome.org/devel/gdk/stable/gdk-Threads.html#GDK-THREADS-ENTER:CAPS "Typically gdk_threads_enter() should be used instead of this macro." > So, it looks like the binary builds for Windows has done something weird to > the macros. The macros are the same on windows. I think the problem is that they use two function pointers declared in gdk.h... GDKVAR GCallback gdk_threads_lock; GDKVAR GCallback gdk_threads_unlock; The import of these symbols works when building an .exe, but ghci is not able to find them. 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
