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

[Jason Dagit]

On Jul 5, 2011 1:04 PM, "Jason Dagit" <dagitj at gmail.com> wrote:
>
> On Tue, Jul 5, 2011 at 12:33 PM, Ian Lynagh <igloo at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20110705/1e18b7fb/attachment.htm>