On 20 July 2005 14:35, John Goerzen wrote:
I'm looking at packaging an event-driven console widget set (CDK) for Haskell using FFI. I know that other event-driven widget sets have Haskell bindings, but I'm not quite sure how to make everything play nice with forkIO.
These systems generally have some sort of an opaque main loop, implemented in C. This loop would usually never return, or perhaps only return once the UI is destroyed.
Is the library thread-safe or not? I mean OS-thread safe. If it is, then you're home and dry: just compile your program with GHC's -threaded option, and any foreign calls that need to run concurrently with Haskell threads must be declared "safe" (which is the default in fact, so instead I should really advise you to mark all calls that don't need to run concurrently as "unsafe", because that's good for performance). If the library isn't thread-safe, then you're in the same boat as Gtk and wxHaskell (I believe) where there are known problems with having a multithreaded Haskell GUI app. You can only have one OS thread (and hence only one Haskell thread) doing GUI operations, and that is the thread in the main loop. You have to somehow set up a communication between your other Haskell threads and the thread running the main loop - perhaps you can send requests of type (IO ()) down a channel to the main loop thread which wakes up occasionally to run them, for example. Cheers, Simon