Re: [Haskell-cafe] How to ensure code executes in the context of a specific OS thread?

On Wed, Jul 6, 2011 at 2:20 AM, Simon Marlow wrote:

On 05/07/2011 20:38, Jason Dagit wrote:

...

On Tue, Jul 5, 2011 at 12:11 PM, Simon Marlow  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.

I did read this section: http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurren... And I played with some of the functions there. What I didn't take away from this was the guarantee that main runs on the original OS thread. I had the impression that it was running from some bound thread, possibly created via runInBoundThread. I think that ghc and ghci are quite different in this regard. It would probably be good to mention that distinction. Jason