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

On Thu, Jul 7, 2011 at 12:41 AM, Simon Marlow wrote:

On 06/07/2011 21:19, Jason Dagit wrote:

...

On Wed, Jul 6, 2011 at 12:52 PM, Simon Marlow  wrote:

...

On 06/07/11 17:14, David Barbour wrote:

...

On Wed, Jul 6, 2011 at 8:09 AM, Simon Marlowmailto:marlowsd@gmail.com>  wrote:

   On 06/07/2011 15:42, Jason Dagit wrote:

       How can I make sure my library works from GHC (with arbitrary

       user threads) and from GHCI?

   Right, but usually the way this is implemented is with some    cooperation from the main thread. [...] So you can't just do this    from a library - the main thread has to be in on the game. I suppose    you might wonder whether the GHC RTS could implement runInMainThread    by preempting the main thread and running some different code on it.      [...]

I think the real issue is that GHC has a different behavior than GHCi, and I think this causes a lot of difficulties for people working on GUI and other FFI integration.

Perhaps it would be possible to reverse the default roles of threads in GHCi: the main thread run user commands, and a second bound thread will process user interrupts and such.

Well, GHCi has no main, so it doesn't seem surprising (to me) that it's different.

However, if -fno-ghci-sandbox doesn't have any drawbacks we could just make it the default.  I don't actually remember why we run each statement in a new thread, I think it just seemed like a prudent thing to do.

+1 for this change.  I'm not sure how we would know if there are drawbacks.

Now that I think about it, the original reason may have been that if the computation grows a large stack, having it in a separate thread means GHCi can recover the memory.  However we have been able to recover stack memory for some time now, so that is no longer an issue.

Then by all means, please make -fno-ghci-sandbox the default! :) Thanks Jason