On Tue, Jul 5, 2011 at 12:11 PM, Simon Marlow
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? 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.
In GHCi it's a different matter, because the main thread is running GHCi itself, and all the expressions/statements typed at the prompt are run in forkIO'd threads (a new one for each statement, in fact). If you want a way to run command-line operations in the main thread, please submit a feature request. I'm not sure it can be done, but I'll look into it.
I'll try Ian's suggestion of -fno-ghci-sandbox when I get a chance. Thanks, Jason