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

[Simon Marlow]

On 07/07/2011 08:41, Simon Marlow wrote:
> 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.

I discovered the real reason we run statements in a separate thread: the 
GHCi debugger.  If the computation stops at a breakpoint, then we have 
to save the context and resume GHCi, which can only be done if the 
computation was running in a separate thread.

The way things are arranged right now, each stopped computation gets a 
different thread.  What you want is for all these to be on the main 
thread.  It might be possible to arrange this, but it would require some 
non-trivial reorganisation in the implementation of interactive 
evaluation (compiler/main/InteractiveEval.hs).  I'm going to have to 
leave this for now, sorry.  In the meantime you'll still be able to use 
-fno-ghci-sandbox, but the debugging features in GHCi will be disabled.

Cheers,
	Simon