
On Jul 5, 2011 1:04 PM, "Jason Dagit"
On Tue, Jul 5, 2011 at 12:33 PM, Ian Lynagh
wrote: On Tue, Jul 05, 2011 at 08:11:21PM +0100, Simon Marlow wrote:
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.
We already have a way: -fno-ghci-sandbox
I've removed all my explicit attempts to forkIO/forkOS and passed the command line flag you mention. I just tried this but it doesn't change the behavior in my example.
I tried it again and discovered that due to an argument parsing bug in cabal-dev that the flag was not passed correctly. I explicitly passed it and verified that it works. Thanks for the workaround. By the way, I did look at the user guide for options like this and didn't see it. Which part of the manual is it in? Can I still make a feature request for a function to make code run on the original thread? My reasoning is that the code which needs to run on the main thread may appear in a library in which case the developer has no control over how ghc is invoked. The alternative appears to be context specific workarounds. I think that a general solution, if possible, will make gui libraries easier to develop for Ghc. I'm hooping it's as simple as exposing a pthreads call. Thanks, Jason