Integrating ghc's rts into other single-threaded frameworks

[Wolfgang Thaller]

> So here's what I don't understand: we make a non-blocking call to 
> gtk+'s
> main loop

So far, so good.

> (which makes a blocking call in a new OS thread).

With (the current version of) GHC's threaded RTS, there's only one OS 
thread involved until you spawn a second thread (with forkIO or 
forkOS).

> So we get
> callbacks from gtk in this other thread, which is fine.

I'd expect you to get the callbacks in the same thread as the call-out, 
that is in your main thread (the same thread that was used to run the 
"main" action).

> However if we
> launch any other Haskell threads that want to update the GUI in any way
> they need to make calls in the GUI OS thread. But the GUI OS thread is
> not in Haskell land at this point, it's blocked in a call to the gtk+
> main loop.

Correct. GTK will need to help you a bit here for this to work.
Many GUI toolkits offer a "post event to main event loop" function that 
may be called from any thread, at any time. You could use that to send 
a StablePtr (IO ()) to the GUI thread.
You could also use a pipe to send that StablePtr to the GUI thread (I'm 
sure you can make GTK's event loop wait until a file descriptor is 
readable).
I don't think that this machinery should take more than ten or twenty 
lines of code to implement.
The absolute worst-case scenario involves registering a timer callback 
with GTK and regularily polling a Chan (IO ())...

Cheers,

Wolfgang