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
