On Sep 15, 10:00 pm, oldmoe <[EMAIL PROTECTED]> wrote: > > But if the Fiber is blocked, it can't yield. In the comments of the > > same article oldmoe states Fibers are not pre-emptive. > > > So green-threads without a scheduler and manual flow-control? Meh. > > Fibers (Coroutines) have to yield manually, even though this might > sound like a bad thing, it has the following benefits: > > 1 - No thread scheduling overhead (context switching is only done on > demand)
Sure. Definitely seems like a win over green-threads. > 2 - No race conditions Score another win for Fibers over threads. > 3 - It can be abstracted away in the IO libraries, you never need to > call Fiber.yield manually when you are using NeverBlock It's not really a feature unique to Fibers, but sure, it's a nice usage. > This model has been used successfully before for abstracting > nonblocking evented IO, examples are Lua's nonblocking IO libraries > and C Protothreads (not sure why they are called threads!) > > oldmoe Don't get me wrong. It's been an enlightening and interesting discussion. I just wanted to clear the air and clarify that Fibers are basically green-threads where you get to control when a context-switch happens, and not some green-thread-scheduler's obscure rules that kick in whenever a conditional is encountered or a block enters or exits. So practically thinking I personally think they're a step forward and wouldn't mind seeing them replace green-threads entirely. On the other hand they are in no way a suitable replacement for native- threads. They don't allow true concurrent access on one to N number of cores. Any blocking operation wrapped up in a Fiber is still a blocking operation. Also, I think I should point out the threading comparison you made on your blog produced some interesting data, but it was a unique take on threads. 100,000 threads is a bit outrageous. It's a balancing act. You use threads to increase performance or balance resources. You shouldn't create so many threads you're spending most of your CPU time context switching. You would only add as many threads as you can effectively use. In the case of a database driver, that's probably about as many as you allow database connections for. For me the magic number is trial and error. There's probably a more scientific way to go about it. Once you've maxed out a resource such as IO or CPU however, more threads generally isn't the answer in my experience. With Ruby being so CPU intensive, my off-hand guess is that the number is actually generally lower than other platforms. My guess is probably around 20. Another side of the coin is that measuring thread startup is not as meaningful as it might appear since you'd typically use a ThreadPool or dedicated event-driven workers for a specific task that stay up for the life of the application (typical in WinForms development anyways) which makes it a non-issue. So yeah, it appears Fibers are a step forward, but they don't strike me as out-right substitutions for the same sorts of problems you might apply native-threads to. With a GIL in 1.9, I have to consider if JRuby or IronRuby (once it matures) might not hold the promise of a much more complete package. -Sam ( hoping I haven't stuck my foot in my mouth too much ;-) ) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "DataMapper" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/datamapper?hl=en -~----------~----~----~----~------~----~------~--~---
