On 20 July 2005 16:23, John Goerzen wrote:
On Wed, Jul 20, 2005 at 04:10:38PM +0100, Simon Marlow wrote:
On 20 July 2005 14:35, John Goerzen wrote:
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).
That's half of the question. The other half is: what is the canonical way of handling this mainloop that doesn't return from Haskell? Do we just treat it that way in Haskell as well, or would some people forkIO it?
You could forkIO the main loop if you want; it shouldn't make any difference, except that GHC terminates the program when the main thread completes, so it's more convenient to have the main loop run in the main thread, so that the program terminates when the main loop returns.
Does any part of your answer vary depending on whether the Haskell threads in question are forkIO threads or forkOS threads? I imagine that it might.
No, and I don't think you need forkOS here. This paper might help shed some light: http://www.haskell.org/~simonmar/papers/conc-ffi.pdf
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
What about multiple forkIO threads?
You should think of Haskell as having a one-to-one mapping between OS threads and Haskell threads. The only difference between forkIO and forkOS is that a forkIO thread can migrate from one OS thread to another, whereas a forkOS thread always runs on the same OS thread. This difference is therefore only visible when you make FFI calls, because there's no way in Haskell to tell what OS thread you're running on. In practice, GHC uses an optimised implementation to take advantage of the fact that forkIO threads are allowed to migrate from one OS thread to another, and it runs all the forkIO threads using a small pool of worker OS threads. The design of forkIO/forkOS and the FFI is carefully crafted to accommodate both GHC's optimised implementation and simpler implementations such as one-to-one or a giant lock.
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.
I imagine there could be exceptions to this.. For instance, perhaps a given operation needs to do 5 things, perhaps simultaneously, before displaying a result. It could, perhaps, fire off five threads and just not display a result until all five have terminated, yes?
Sure, but it's just a matter of converting direct GUI calls into RPCs to the GUI thread, using some appropriate RPC mechanism. Cheers, Simon