+1 for fibers. There is a class of problems made much simpler and/or possible with fibers that are not viable w/threads.
Would love to see this make its way into MacRuby. Sent from my iPhone On Aug 11, 2010, at 6:06 AM, Scott Thompson <ea...@mac.com> wrote: > > On Aug 11, 2010, at 7:23 AM, Louis-Philippe wrote: > >> Hi Scott, >> >> If you haven't done so already, you might want to have a look at: >> http://www.macruby.org/documentation/gcd.html >> >> it speaks of MacRuby integrating Apple's latest multi-threading strategy: >> Grand Central Dispatch. > > Grand Central Dispatch is a fine technology, and goes a long way toward > making concurrency much easier to implement. But concurrent execution is > only one form of multitasking and GCD is not a general solution to all > multitasking problems. In this particular case we are talking about > cooperatively scheduled coroutines which is multitasking, but not necessarily > concurrency. > > In Grand Central Dispatch, work is broken up in to a number of small units > and those units are dispatched to queues. Eventually a preemptive thread > will come along and pick up that work, run it (possibly in parallel with > other bits of work). When a thread runs some of the work, however, it runs > that work all the way through. > > Contrast that with a Fiber. Like a block, a fiber represents a unit of work > you need to do, but it's work you can turn your attention to... spend some > time on, and then put down again at predefined spots. Later, when you are > ready, you can pick up that work and continue at the same spot. This is > multitasking, but not concurrency. Consider a simple example: > > my_fiber = Fiber.new do > number = 0 > loop do > Fiber.yield number > number = number + 1 > end > end > > >> my_fiber.resume > => 0 > > >> my_fiber.resume > => 1 > > This is a coroutine. It has it's own execution context which is started with > the first resume, runs up until the yield, and then suspends execution. This > is a simple example, but the coroutine could be calling other subroutines, or > other complex tasks, with the yield suspending execution at any point along > the way. At some point in the future, resume may be called again and > execution continues where it left off up until the next time yield is called. > > This type of multitasking would be hard to implement using GCD because GCD > focuses on concurrency. Since each GCD block runs to completion, the solution > would involve breaking up the Ruby code using the yield statements as > boundaries and then dispatching those blocks to a queue. But that solution > would quickly become untenable if you consider that the yield statements > might come... say... in the middle of a case:while statement, or in the > middle of a complex subroutine chain. > > Another solution you might come up with is to submit the whole Fiber's block > as a single GCD block and implement the yield as acquiring some > multiprocessing lock (a semaphore or a condition lock for example). If you > do that, then you've got the added overhead of a concurrency lock for each > yield and you've submitted a GCD block to a queue that contains an infinite > loop. That block is going to sit at the end of the queue, consuming one of > the threads from the thread pool "forever". If you get a bunch of these > running at once... GCD is not going to be happy with your train cars sitting > on his tracks. > > Please don't get me wrong. I __LOVE___ all the work that has gone into > integrating GCD into MacRuby. But I don't see how GCD is going to help > someone implement the cooperative multitasking of Fibers, a Ruby 1.9 language > feature. > > Scott > _______________________________________________ > MacRuby-devel mailing list > MacRuby-devel@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
