Hi Scott, Because of the way MacRuby is implemented, fibers would need to unwind the stack most of the time you switch continuations, which has poor runtime performance. We will eventually implement continuations which can serve to implement fibers at some point (which is what MRI does I believe), but I wouldn't recommend to use them for anything significant because of the performance impact.
Another issue is that unwinding the stack would likely mess with Objective-C exception handlers, unless they are implemented using exceptions, which would impact performance even worser (because we use dwarf exceptions). I personally believe the GCD model is much more appealing to achieve multitasking, especially now that we enter the multicore age. Laurent On Aug 11, 2010, at 6:06 AM, Scott Thompson 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
