Hi Logan, On Aug 11, 2010, at 2:03 PM, Logan Bowers wrote:
> That's a bummer; it sounds like Fibers will never really be useful on the > MacRuby platform then? :( They could definitely be useful once they are implemented. But I'm not sure there would be a case where using them would be preferable over native threads / GCD. > Out of curiosity, is there a limiting factor in the runtime that prevents the > use of, e.g., makecontext/setcontext or related call? I can't answer that yet, but I remember Patrick investigated the implementation of continuations a while ago. Maybe he can chime here. A very naive implementation based on sjlj could probably be done easily. But it may be unstable if you start mixing continuations with calls to Cocoa APIs. Laurent > Logan Bowers > > On Aug 11, 2010, at 1:56 PM, Laurent Sansonetti wrote: > >> 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 > > _______________________________________________ > 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
