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

On Wed, Jul 6, 2011 at 2:23 AM, Simon Marlow wrote:

On 06/07/2011 07:37, Jason Dagit wrote:

...

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

I'm not sure how that would work.  The programmer is in control of what the main thread does, not GHC.  So in order to implement some mechanism to run code on the main thread, we would need some cooperation from the main thread itself.  For example, in gtk2hs the main thread runs an event handler loop which occasionally checks a queue for requests from other threads (at least, I think that's how it works).

What I'm wrestling with is the following. Say I make a GUI library. As author of the GUI library I discover issues like this where the library code needs to execute on the "main" thread. Users of the library expect the typical Haskell environment where you can't tell the difference between threads, and you fork at will. How can I make sure my library works from GHC (with arbitrary user threads) and from GHCI? As John Lato points out in his email lots of people bump into this without realizing it and don't understand what the problem is. We can try our best to educate everyone, but I have this sense that we could also do a better job of providing primitives to make it so that code will run on the main thread regardless of how people invoke the library. In my specific case (Cocoa on OSX), it is possible for me to use some Cocoa functions to force things to run on the main thread. From what I've read Cocoa uses pthreads to implement this. I was hoping we could expose something from the RTS code in Control.Concurrent so that it's part of an "official" Haskell API that library writers can assume. Judging by this SO question, it's easier to implement this in Haskell on top of pthreads than to implement it in C (here I'm assuming GHC's RTS uses pthreads, but I've never checked): http://stackoverflow.com/questions/6130823/pthreads-perform-function-on-main... In fact, the it sounds like what Gtk2hs is doing with the postGUI functions. Jason