David, The GHC-iPhone port is no different to any other platform with regard to threading. What we (iPwn Studios) do with the video game is this: We have a main.m that feeds some command-line arguments (RTS options) into Haskell_main. The Haskell main function then forkIOs and forkOSs some Haskell threads for its own purposes and then calls back to C on the main thread. The C code then calls the iOS UIApplicationMain function. To delegate processing to the main thread (required by iOS for GUI calls), we then use this code that I got from somewhere: void DelegateToMain__(void* appController, Closure* closure) { AppController* ac = (AppController*)appController; NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init]; [ac performSelectorOnMainThread:@selector(delegateToMain:) withObject:[NSValue valueWithPointer:closure] waitUntilDone:NO]; [pool release]; } - (void) delegateToMain:(NSValue*)closureValue { Closure* closure = (Closure*)[closureValue pointerValue]; closure->run(); } Since we ran the iOS event loop from the Haskell main, and since 'main' always starts on a bound thread (see haddocks for Control.Concurrent), it would be perfectly safe to use the above technique to run Haskell code.
Given the 5 second rule about an iOS app getting shut down... if there are Haskell threads doing Haskell-y kind of work, is there a way of notifying those threads en masse about the shutdown?
Greg already gave you lots of links, so take a look at those. There are two ways: co-operatively, or using killThread. To do it co-operatively, you'll need to just read up. killThread may be simpler. It's important to note that GHC does something that no other language I know of can do: It can kill a thread safely. This is explained in section 3.3 of Simon Marlow's parallel Haskell tutorial (Greg gave this link too): http://community.haskell.org/~simonmar/par-tutorial.pdf Steve On 11/06/11 06:12, David Pollak wrote:
Howdy,
I've got a question about threading and thread models in ghc-iphone.
My understanding is that Haskell has its own threading model that under the covers uses OS threads, but allows for significantly more active threads. Is this a correct understanding? If so, how does the Haskell threading model work on the iPhone? Is it that iOS is close enough to OS X/Darwin that it "just works"?
If it "just works", then how does one marshal an event back onto the iOS "UI thread" so that the display or draw or whatever command can take place on the UI thread? Is there a convention or recipe for doing so? Would it be possible to put an event on the UI event queue that applies an Haskell closure such that the Haskell code that contains the computed value (I'd force the computation before marshaling the event to minimize the actual delay on the UI thread) then mutates the UI based on the computed value?
Given the 5 second rule about an iOS app getting shut down... if there are Haskell threads doing Haskell-y kind of work, is there a way of notifying those threads en masse about the shutdown?
Thanks,
David
-- Lift, the simply functional web framework http://liftweb.net Simply Lift http://simply.liftweb.net Follow me: http://twitter.com/dpp Blog: http://goodstuff.im
_______________________________________________ iPhone mailing list iPhone@haskell.org http://www.haskell.org/mailman/listinfo/iphone