On 05/07/2011 20:38, Jason Dagit wrote:
On Tue, Jul 5, 2011 at 12:11 PM, Simon Marlow<[email protected]> wrote:
On 04/07/11 06:02, Jason Dagit wrote:
Hello,
I'm trying to get some GUI code working on OSX and numerous forums
around the internet keep reiterating that on OSX to correctly handle
GUI events you need to use the original thread allocated to your
process to check for events and to call the Cocoa framework
functionality. Specifically, using a secondary thread (even a bound
thread) is not sufficient with the Cocoa framework.
I looked at the threading documentation in Control.Concurrent for GHC
and it's not clear to me if this is even possible with GHC without
restricting to the non-threaded RTS. This means that using the GUI
library from GHCI is not an option and using multiple OS threads in
the final application is also not possible. This means that some FFI
libraries will be unusable.
In a compiled program, the main thread is a bound thread, bound to the main
OS thread of the process (i.e. the GUI thread in your case). So you can
safely make Cocoa calls using the main thread of your compiled Haskell
program, and from other threads if you add some way to forward operations to
the main thread, like gtk2hs's postGUI.
Is my understanding correct that this is only the case for the
non-threaded RTS?
No - I'm talking about the threaded RTS here. It's trivially true of
the non-threaded RTS too, because there's only one OS thread.
If so, what do you do when you need to use the
threaded RTS? My test was to check if the main thread was bound when
compiling with -threaded. I got the impression that I couldn't
guarantee that the code was running on the original thread.
You do have that guarantee for the main thread. Could you point out the
docs that gave you the opposite impression - I'll see if we can improve
them.
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
