Re: [Gtk2hs-users] Ensuring that something gets executed in the GUI thread

[Ivan P. <iva...@gm...>]

Thank you both for your insight.

I've been looking around and I can't find any way to check if one has
the gdk lock, so a general solution to this problem would require a
global thread-id variable, a custom "pseudo-main" thread and a channel
to post opts to be executed in the main thread with the gdk lock.

I'm writing a reactive library that encloses all widget properties
into reactive values, and should alleviate this pain (also, I'd say
inversion of control goes away). Although users can still combine gtk
event handlers with reactive values in the same application (should be
safe), the idea is that they use this new API and all thread-handling
is done for them.

Best

Ivan

On 13 May 2015 at 08:48, koral <ko...@ma...> wrote:
>> > (Since we don't have a Gtk monad, and to avoid passing the threadID
>> > around, a dirty workaround could be to store the GUI thread ID in some
>> > global variable and create wrapping functions that get the current GUI
>> > thread, compare and use postGUI(A)Sync only if different.)
>> >
>>
>> I think this solution might work and is not as bad as it seems since there already is some global state that ensures that gtkInit is not called several times.
>
> I had a try at this some time ago, and I noticed that, unexpectedly, `Control.Concurrent.myThreadId` doesn't return a constant value when it is called from a signal handler.
> For example (I've just reproduced it with the demo program bundled with webkitgtk3):
>
>   -- Main thread
>   print =<< myThreadId
>
>   -- Open uri when user press `return` at address bar.
>   addressBar `on` entryActivated $ do
>     print =<< myThreadId -- Will print a distinct value each time it is invoked
>     -- (...)
>
> While the documentation says that signal handlers are run within gtk's main loop thread, this experiment suggests that a fork thread is created to run a handler, and that the main loop waits for its termination.
> So unless I'm mistaken, it looks like you can't rely on the thread ID to decide whether you can safely call postGUISync.
>
> Cheers.