Could you share some, or maybe provide a link? I'm interested in the topic, but unfamiliar with any specific use-cases.
Matt On Aug 11, 2010, at 10:15 AM, Logan Bowers wrote: > +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
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
