Woah there, cowboy! No need to pull out the "patches welcome" gun, just sharing a use case from the field. I use Ruby 1.9 now, I hope to someday switch to MacRuby. It'd be a shame if the implementation of fibers didn't take into account the situations in which they might be used.
You're, of course, free to use GCD for everything; having used block-based, queue-dispatched, thread-pool frameworks for concurrency before, I'll still with my fibers. :) Logan Bowers On Aug 13, 2010, at 1:34 PM, Jordan K. Hubbard wrote: > > On Aug 13, 2010, at 12:55 PM, Logan Bowers wrote: > >> The state-of-the-art for handling highly concurrent loads is to use an >> event-driven I/O framework. Evented I/O is difficult for the same reasons >> using a GCD queue is difficult, the application and all dependencies have to >> be designed from the ground up to unwind the stack at every point where I/O >> may occur (no blocking calls). For an extra 4kB/request, Fibers mean you >> don't have to rewrite your application and all its dependencies from the >> ground up. As someone who's worked with many event-I/O frameworks over the >> years, I can say it's a HUGE productivity boost. > > This statement makes me think that you may not actually understand GCD, > because you don't have to do any of that. GCD will deal with threads which > park themselves waiting for I/O just fine, dealing with I/O events equally > well with dispatch sources. None of the "problem statements" you list in > defense of Fibers are actually problems on this platform unless you go well > out of your way to actually make them problems (enqueue some absurd number of > operations with no flow-control, for example, or attempt to open thousands of > sources at once). > >> I think that's all I can say on the subject, you can believe fibers are >> useful in such a scenario or not; if you think not, I encourage you to >> attempt to write software typically authored with a thread-per-request model >> instead in an evented/non-blocking model and compare the levels of effort. >> As I think Easco mentioned, we can conclude that because Fibers have unique >> properties not present in Threads or GCD, they are useful when those >> properties add value. One would use a different abstraction otherwise. > > Again, GCD does not use a thread-per-request model so I'm not sure why you > would consider that a point of comparison. Remember, nobody is defending the > POSIX pthread APIs here, they're saying that GCD makes Fibers less relevant, > so it might pay dividends for you to look into GCD a bit more (particularly > in the context of how MacRuby supports it) before categorically deciding that > Fibers are really key to solving your problems. > > It's also been said many times already, but I'll say it again: No one is > saying Fiber support would be undesirable, if for Ruby 1.9 compatibility > reasons alone. What they're saying is that someone needs to VOLUNTEER to do > the work involved or the discussion is and will remain purely academic. > MacRuby, even with the generous support of Apple, is still a volunteer-driven > open source project and the further one gets from the critical-path > functionality (many bugs against which still remain to be dealt with in > Trac), the lower the priority goes. If Logan and others in this discussion > were willing to demonstrate as much passion for actually implementing Fibers > as they have for discussing them, this conversation would be both shorter and > more fruitful. :-) > > - Jordan > > _______________________________________________ > 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
