Sure, I recommend you look at http://www.stackless.com/ (a fiber-supporting implementation of Python), and NeverBlock (http://www.espace.com.eg/neverblock/).
Stackless Python I believe is used extensively on the EVE Online MMO runtime as fibers/coroutines make for very natural use of the actor pattern. I personally want fibers for the network applications. We use long-lived connections for, e.g., Comet-style HTTP requests. Right now we have to shunt those into a non-blocking, evented I/O server (twistd) since writing large applications using entirely non-blocking I/O just isn't tenable. non-blocking code is far more complex and far less composable than synchronous code. Fiber support makes it possible to use both blocking and non-blocking code in the same application. Logan Bowers On Aug 11, 2010, at 10:35 AM, dan sinclair wrote: > The em-synchrony project wraps a bunch of EventMachine code in fibers: > http://github.com/igrigorik/em-synchrony > > I know the author was looking at MacRuby and trying to figure out if fibers > worked just the other day. > > dan > > > > On 2010-08-11, at 1:19 PM, Matt Massicotte wrote: > >> 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 > > _______________________________________________ > 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
