On Wed, Jul 6, 2011 at 12:52 PM, Simon Marlow <marlo...@gmail.com> wrote: > On 06/07/11 17:14, David Barbour wrote: >> >> >> On Wed, Jul 6, 2011 at 8:09 AM, Simon Marlow <marlo...@gmail.com >> <mailto:marlo...@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. Jason _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
