RE: Integrating ghc's rts into other single-threaded frameworks
| I'm thinking about how to make threaded Haskell program work nicely with | Gtk+ (the widget toolkit) and whether the new threaded rts will help or | not. | ... | | Would bound threads help? I'm not sure I understand the idea very well. That's *exactly* what the bound-threads idea is for. It's implemented in GHC 6.2.1 (see the bound-thread operations in Control.Concurrent). There is a more detailed writeup about bound threads that I think we neglected to complete and publish. Wolfgang Thaller is the main author, and I hope he may pick this up. Meanwhile we'll put the current draft on the GHC site. Simon
On Wed, 2004-05-05 at 14:55, Simon Peyton-Jones wrote:
| I'm thinking about how to make threaded Haskell program work nicely with Gtk+ (the widget toolkit) and whether the new threaded rts will help or not. | Would bound threads help? I'm not sure I understand the idea very well.
That's *exactly* what the bound-threads idea is for. It's implemented in GHC 6.2.1 (see the bound-thread operations in Control.Concurrent). There is a more detailed writeup about bound threads that I think we neglected to complete and publish. Wolfgang Thaller is the main author, and I hope he may pick this up. Meanwhile we'll put the current draft on the GHC site.
So here's what I don't understand: we make a non-blocking call to gtk+'s main loop (which makes a blocking call in a new OS thread). So we get callbacks from gtk in this other thread, which is fine. 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. Duncan
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
participants (3)
-
Duncan Coutts -
Simon Peyton-Jones -
Wolfgang Thaller