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

[Jason Dagit]

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