Lapis/Openresty where do the superpowers they come from?

[Martin Felis]

Hi there!

I have been looking at the Lapis framework over the weekend and it felt pretty good. On it's webpage it states:

"... With the power of Lua coroutines code is written synchronously but runs asynchronously, without all that callback spaghetti seen in other asynchronous platforms..."

Now I was wondering where exactly the magic is happening. I do know a bit about Lua's coroutines, especially their use in http://www.lua.org/pil/9.4.html. Now I was wondering where do they happen in Lapis or Openresty in general. After some searching I am guessing it is due to the cosockets in the HttpLuaModule. Furthermore the modules listed in http://wiki.nginx.org/HttpLuaModule#Description make use of the HttpLuaModule. So when using them it internally uses Lua's coroutines and as a user of the listed modules one does not have to worry about manually handling the coroutines.

Is this correct or am I confusing things here?

Thanks for all the work and keep it up!

Cheers,
Martin

[leaf corcoran]

Lapis doesn't use cosockets in its implementation currently. (Although I'd like to make the switch in the future.) All asynchronous actions (queries, http requests) are triggered through ngx.location.capture: http://wiki.nginx.org/HttpLuaModule#ngx.location.capture

--
You received this message because you are subscribed to the Google Groups "openresty-en" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openresty-en...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Yichun Zhang (agentzh)]

Hello!

On Mon, Mar 3, 2014 at 10:19 AM, Martin Felis wrote:
> Now I was wondering where exactly the magic is happening. I do know a bit
> about Lua's coroutines, especially their use in
> http://www.lua.org/pil/9.4.html.

The magic happens under the hood, automatically, everytime you call a
IO-like ngx_lua primitives, like the cosocket API,
ngx.location.capture*() API, ngx.sleep(), ngx.flush(true), and etc.
Basically, if the call finds it impossible to complete the request
immediately, then it automatically *yields* the current Lua "light
thread" (implemented upon Lua coroutines), and later *resumes* the
thread later upon the corresponding events. The user Lua code that is
able to run the nonblocking IO primitives is always run inside a
"light thread" implemented atop Lua coroutines, like the Lua code
specified by content_by_lua and access_by_lua directives.

Regards,
-agentzh