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

[Simon Marlow]

On 06/07/2011 21:19, Jason Dagit wrote:
> On Wed, Jul 6, 2011 at 12:52 PM, Simon Marlow<marlowsd at gmail.com>  wrote:
>> On 06/07/11 17:14, David Barbour wrote:
>>>
>>>
>>> On Wed, Jul 6, 2011 at 8:09 AM, Simon Marlow<marlowsd at gmail.com
>>> <mailto:marlowsd at 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.

Cheers,
	Simon