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
Hi David, This tutorial on parallel haskell was recently made: http://community.haskell.org/~simonmar/par-tutorial.pdf You are probably interested more in the concurrency http://www.haskell.org/haskellwiki/Concurrency aspect of what is sometimes just referred to as "Parallel Haskell" http://www.haskell.org/haskellwiki/Parallel There is a nice picture of the architecture of haskell threads here: http://stackoverflow.com/questions/958449/what-is-a-spark-in-haskell I have no idea how this plays out on the iOS. I am interested in hearing about that. Greg Weber On Fri, Jun 10, 2011 at 11:12 AM, David Pollak < feeder.of.the.bears@gmail.com> 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
I haven't looked specifically at ghc-iphone, but as it's just using the GHC
RTS, I'd assume the situation isn't very different from regular GHC. The
deal there is that the GHC runtime gives you green threads, and
forkIO/forkOS start new green threads. These have tiny overhead and are
scheduled cooperatively by the RTS (every time you go to allocate, which is
all the time in your average haskell program, the RTS checks to see if it
needs to switch). IO and stuff is using select behind the scenes (ghc-iphone
is built on an older version of GHC that still used select, iirc). The RTS
uses a thread pool that you specify by passing arguments like +RTS -N3 (for
three threads) to your program.
You can't actually have "bound threads" in GHC, but forkOS does give you the
guarantee that any foreign calls you make from the green thread will be made
from the same OS thread. And that should not be observably different from
ensuring all your code runs on the same OS thread.
So to address your question more directly, the way I'd probably approach
what it seems you want to do: create a new Chan for events you want to
happen from a single thread, then forkOS a reader that reads forever (the
Control.Monad.forever) and runs your foreign functions, then all your other
green haskell threads (forkIO is good enough for them) can write to the Chan
(it's designed to be safe for concurrent access and will block if necessary)
and will thus be talking to the foreign-talking thread.
Hope this helps,
Dan
On Fri, Jun 10, 2011 at 2:12 PM, 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
Dan and Greg,
Thanks for the most excellent advice and pointers, and in near-real-time,
too!
Rock on.
David
On Fri, Jun 10, 2011 at 11:32 AM, Daniel Peebles
I haven't looked specifically at ghc-iphone, but as it's just using the GHC RTS, I'd assume the situation isn't very different from regular GHC. The deal there is that the GHC runtime gives you green threads, and forkIO/forkOS start new green threads. These have tiny overhead and are scheduled cooperatively by the RTS (every time you go to allocate, which is all the time in your average haskell program, the RTS checks to see if it needs to switch). IO and stuff is using select behind the scenes (ghc-iphone is built on an older version of GHC that still used select, iirc). The RTS uses a thread pool that you specify by passing arguments like +RTS -N3 (for three threads) to your program.
You can't actually have "bound threads" in GHC, but forkOS does give you the guarantee that any foreign calls you make from the green thread will be made from the same OS thread. And that should not be observably different from ensuring all your code runs on the same OS thread.
So to address your question more directly, the way I'd probably approach what it seems you want to do: create a new Chan for events you want to happen from a single thread, then forkOS a reader that reads forever (the Control.Monad.forever) and runs your foreign functions, then all your other green haskell threads (forkIO is good enough for them) can write to the Chan (it's designed to be safe for concurrent access and will block if necessary) and will thus be talking to the foreign-talking thread.
Hope this helps, Dan
On Fri, Jun 10, 2011 at 2:12 PM, David Pollak < feeder.of.the.bears@gmail.com> 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
-- 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
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
participants (4)
-
Daniel Peebles -
David Pollak -
Greg Weber -
Stephen Blackheath [to GHC-iPhone]