Hello!
On Mon, Apr 28, 2014 at 12:40 AM, Alain Meunier wrote:
> I train myself on sockets.
> After reading the resty redis, I still cannot understand how a script can
> get back the answer from a, say, redis database in an async fashion from
> resty.
>
What really matters here regarding performance is not sync vs async,
but rather blocking IO vs nonblocking IO. That is, whether the IO
operations would block any OS threads. See also
http://www.kegel.com/c10k.html
The lua-resty-redis library uses nonblocking IO so its IO operations
will never block any OS threads.
> Imagine we have 1000 requests coming on a socket. The non blocking socket
> then the event loop stacks up the requests which are then processed in a
> while loop (that is what I learnt).
>
No, this is wrong. Different requests cannot access the same socket at
the same time though you can reuse the underlying connections across
requests but in that case different requests access the socket *in
turn* rather than *at the same time*. If you try to do that, you'll
get the "socket busy" or "bad request" error message from
lua-resty-redis's methods.
> The points I miss are :
> - are the different reads really launched/done async ?
For every socket read that cannot complete immediately, ngx_lua will
suspend (or yield) the current Lua coroutine (or "light thread") and
give the control back to the nginx event loop. When the nginx event
loop sees new events on the socket in question, then nginx event loop
will give the control back to ngx_lua and ngx_lua will resume the
suspended (or yieded) Lua coroutine and continue running its
subsequent Lua code.
So from the Lua programmer's perspective, the reads are synchronous.
But from the operating system's perspective, no OS threads can be
blocked by the socket reads (and writes and connects).
For this reason, I suggest you should stop using the terms "sync" and
"async", because they can be really confusing.
> - how resty is able to get the data back from redis that corresponds to the
> initial query and not messing it up with other async queries that may have
> been launched in the mean time ?
>
See above.
Best regards,
-agentzh
