> Ok, let me re-phrase that. Fibers are GREAT. "Just" sounds dismissive. > It's not. What I'm trying to say is that (again, as far as I know) > Neverblock is _not_ an implementation of asynchronous API for > Postgres. So it lets you run multiple connections concurrently. Good. > It still blocks. That thread stalls until the database finishes up > it's query execution. Just not the whole interpreter.
The thread will not block, only the fiber issuing the IO will. And you can have many fibers living in the same thread at a much lower cost than spawning multiple threads in your application. > I'm also not entirely sure that Fibers offer any advantages over a > ThreadPool based system in conjunction with Asynchronous database > drivers, so we'll probably stick to the ThreadPool solution once that > support is in since having more fibers than actual threads and/or open > connections obviously doesn't buy you a whole lot at the O/RM level > (though you're certainly free to take advantage of them at the > application level). I am sure some people would like a Fiber implementation as it is much easier than writing thread safe implementations. I am aware though that the project is limited on resources and must prioritize, hence I offer to implement the Fiber based pool myself, just drop me a line if you are interested regards Mohammad A. Ali oldmoe.blogspot.com --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
