Closed voronianski closed 10 years ago
most of the rocks or luarocks modules are not going to be able to enter the libuv event loop. A native driver would probably be preferable.
@rphillips do you mean native C driver for example (https://github.com/mongodb/mongo-c-driver)?
My experience is most existing rocks assume blocking I/O which isn't compatible with the luvit event loop. Also the way rocks are package often isn't compatible with the luvit module system. Personally, I would write a mongo driver in pure Lua.
There is a company using my luv project (same event model as luvit, but much more minimal) that also needs to talk to mongo. If I remember correctly, they are using node for the mongo part and talk to it through some rest interface from Lua. On Jul 14, 2014 3:52 AM, "Dmitri Voronianski" notifications@github.com wrote:
@rphillips https://github.com/rphillips you mean native C driver - https://github.com/mongodb/mongo-c-driver ?
— Reply to this email directly or view it on GitHub https://github.com/luvit/luvit/issues/477#issuecomment-48877552.
@creationix thanks for this info. What do you think about https://github.com/dvv/luvit-worker it states like:
"Unblock" blocking API
I know that was an experiment Vladimir Dronnikov did. I seem to remember it worked fairly well for him. But even if it works as described, using threads so you can use blocking libraries in a non-blocking event loop won't scale well unless the thread count stays low. It depends on your use case and needs.
On Mon, Jul 14, 2014 at 7:57 AM, Dmitri Voronianski < notifications@github.com> wrote:
@creationix https://github.com/creationix thanks for this info. What do you think about https://github.com/dvv/luvit-worker it states like:
"Unblock" blocking API
— Reply to this email directly or view it on GitHub https://github.com/luvit/luvit/issues/477#issuecomment-48896228.
For example from https://rocks.moonscript.org/ or http://luarocks.giga.puc-rio.br/ such as modules for operating with
mongodb
, etc?