7 ms·
I have used this idiom to great results in my project (https://github.com/raksoras/luaw https://github.com/raksoras/luaw). Basically, request:read() hooks up in
by raksoras 11y ago
I have used this idiom to great results in my project (https://github.com/raksoras/luaw https://github.com/raksoras/luaw). Basically, request:read() hooks up into libuv (node.js' excellent async IO library) event loop and then yields. Server is now free to run next coroutine. When socket underlying the first request is ready with data to read libuv event loop's callback gets fired and resumes original coroutine.
- meric 11y agoThat's awesome. You've me hooked. For postgres database access, what library do you suggest? Also, I remember lua-nginx can also do non-blocking IO in blocking style code. (http://wiki.nginx.org/HttpLuaModule http://wiki.nginx.org/HttpLuaModule, http://openresty.org http://openresty.org) How does luaw compared to that?
- raksoras 11y agoRight now it's just a HTTP server and REST framework. It's a very first release and I don't have any DB drivers for it yet- they would need to be non-blocking as you mentioned. I have plans to write dbslayer like "access DB over REST" service as a companion to Luaw so that it can use any and all databases that have JDBC drivers available without having to write non-blocking driver specially for each new database. This kind of arrangement where DB connection pooling is abstracted out of application server itself has other advantages related to auto-scaling in cloud and red/black or "flip" code pushes at the cost of slightly more complex deployment. All depends on how much spare time I actually get :(