On Jul 5, 2011 1:04 PM, "Jason Dagit" <dagitj@gmail.com> wrote:
>
> On Tue, Jul 5, 2011 at 12:33 PM, Ian Lynagh <igloo@earth.li> 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