Re: [Gtk2hs-users] enforcing thread safety via the type system

[Axel S. <Axe...@in...>]

Hi Claude,

On 19.05.11 22:41, Claude Heiland-Allen wrote:
> Hi everyone,
>
> Some discussion in #haskell the other day might be of interest:
>
> around half way down, at 11:42:09 to 11:53:08
> http://tunes.org/~nef/logs/haskell/11.05.18
>
Ok.
> In essence, I think it would be fantastic if there were a way to improve
> the robustness of GTK with the threaded GHC Haskell runtime, perhaps
> something like this?
>
> postGUISync :: GTK a ->  IO a
> postGUIAsync :: GTK () ->  IO ()
>
> with non-thread-safe GTK functions (all of them?) being
> :: ... GTK a
> instead of
> :: ... IO a
> with MonadIO GTK.
>
> Similarly synchronous callbacks from GTK in the "right" thread would be
> :: ... GTK a
>
So first of all, while there are some functions in Gtk2Hs that modify 
Haskell data structures, most call out to some C function that normally 
reads or modifies some state there. Using concurrentcy here means that 
calling Gtk functions must only happen from the thread that called 
initGUI or by postGUISync and postGUIAsync and addIdle,...  However, an 
exception are data structures that are independent from Gtk's main 
state, like a Cairo graphics context. But you're right, it would mean 
most Gtk functions would have to live in that Monad.

You could put everything into a GTK wrapper monad and bourdon the user 
with lifting functions all the time. This
is really a killer if you actually do have a lot of functions that take 
an IO action as argument as you then would have to wrap GUI instructions 
in a postGUISync even though it is the correct thread. IHMO, using a 
different monad that keeps IO and GTK functions separate leads to a 
software engineering nightmare as you start writing functions in the GTK 
monad only to find out later that you would like to call them from the 
IO monad as well.

However, if it's really such a big problem as Duncan suggests, then it 
might be wiser to wrap every C call with a test if the current thread is 
the initGUI thread and, if not, wrap the call in a postGUISync. That 
would be slow for calls from other threads, but at least correct. The 
slowdown might not be as bad as it sounds (every function!), since the 
number of GUI calls from different threads should be small. If you 
experience a performance problem, you can still wrap a longer sequence 
of calls in postGUISync and have the inter-thread communication done 
once. I have added a provision to our c2hs to actually do such a 
wrapping automatically, but I haven't gone through with it yet. I 
getting inter-thread communication right is such a big deal, we could 
implement this test. Or we could implement the test and abort the 
program when a Gtk function is called from some other than the initGUI 
thread. That would give some sort of on-line testing (aka run-time 
verification) that people use postGUISync everywhere it is needed.

In short: I'm against the wrapper moand for software engineering 
reasons. Haskell would need real subtyping to make this fly. As it is 
now, it's too big a bourdon for the programmer.

Cheers,
Axel

> I haven't checked the GTK build system to know how feasible it is to
> implement, and naturally this change probably will require much user
> code to be updated, but I think it would be worth it for the extra
> safety/correctness enforced by the compiler.  Maybe something to think
> about for GTK3, if it would be somewhat incompatible [1] with GTK2 anyway?
>
> [1] http://developer.gnome.org/gtk3/stable/gtk-migrating-2-to-3.html
>
>
> Thanks,
>
>
> Claude
>
> ------------------------------------------------------------------------------
> What Every C/C++ and Fortran developer Should Know!
> Read this article and learn how Intel has extended the reach of its
> next-generation tools to help Windows* and Linux* C/C++ and Fortran
> developers boost performance applications - including clusters.
> http://p.sf.net/sfu/intel-dev2devmay
> _______________________________________________
> Gtk2hs-users mailing list
> Gtk...@li...
> https://lists.sourceforge.net/lists/listinfo/gtk2hs-users