[Gtk2hs-users] ANNOUNCE: GHC 6.12.3 Release Candidate 1

[Axel Simon]

On 27.05.2010, at 19:50, Bulat Ziganshin wrote:

> Hello Axel,
>
> Thursday, May 27, 2010, 8:42:08 PM, you wrote:
>
>> - you use -threaded to compile your program
>> - you only use postGUISync and postGUIAsync from threads different to
>> the Gtk2Hs thread
>
>> Is this true? If yes, I'll give you an elaboration on how threads are
>> supposed to work in Gtk+ (I think I finally understood this!) and  
>> what
>> I've changed in 0.11.0.
>
> i'm among (probably many) developers who interested to hear it. i
> believe that gtk2hs uses thread where it was initialized as main (this
> thread should be bound so it's either main thread or one created with
> runInBoundThread/forkOS) and the everything should either run in this
> thread directly, or in signal hadlers (that are executed in this
> thread) or via postGUISync/postGUIAsync. moreover postGUISync can't be
> used inside main GUI thread due to locking
>
> as you may remember, once i proposed to add wrapper that is equal to
> id in main GUI thread but equal to postGUISync in other threads. or
> even better, wrap all gtk2hs operations in this wrapper

Yes, I should perhaps dig that up and implement it. I actually suspect  
that Christian ran either into this problem or that he doesn't compile  
with -threaded. Hopefully it's one of those two options and not  
another concurrency bug in Gtk2Hs.

So the story with the threads is as follows:

You can use just a single thread. This is done when you compile  
without -threaded. You need to do the 'addIdle 50 >> yield' trick.

You can use the -threaded option to ghc or you use ghci. Now there  
exists one lock for the whole of Gtk+.

This lock  must be acquired before gtk_init is called. (This is what I  
fixed before the release: without it, it worked on Unix but not on  
Windows.) The lock remains acquired by the OS thread that calls Gtk+.  
In particular, it remains acquire as long as signals are pending and  
dispatched.

The only time this look is released is when Gtk+ enters its main loop.  
It may then block on input or run an idle handler.

During this time, it is possible for a different OS thread (or any odd  
Haskell thread that may or may not run in a different OS thread) to  
acquire the lock, modify some widget state and release the lock.  
However, most widget methods call also to the OS and accessing the  
Win32 API from more than one OS thread is not possible due to Win32  
using some thread-local state. Thus, using this method for concurrent  
updates is not recommended.

Enter postGUIAsync. This method will add an idle handler to the Gtk+  
main loop (this is done by glib in a thread safe way) which executes  
an action from the idle handler. This idle handler will be called from  
the main loop and thus be in the Gtk+ OS thread. The action can  
therefore safely access all widget methods. Since the action is  
performed in the Gtk+ OS thread, no expensive computation should be  
done, merely the widgets should be updated.

I hope this helps to clarify the thread situation in Gtk+.

Cheers,
Axel