Thibault Charbonnier

@p0pr0ck5 Gotcha. > The biggest change came from concurrent usages of get_keys, since that operation no longer needs to hold a mutex. Yes, I am particularly interested in this win...

@spacewander This is precisely what we have been doing for the past few years, and what this PR tries to get rid of :) The goal here is to avoid...

Especially considering the maintainability cost seems to be relatively low. No Nginx patch required, a dependency on an init, process that is very unlikely to ever change, and a self-contained...

> we could make this work on a much lower level, by dynamically configuring all the nginx main/http/stream/server/location blocks in Lua Yes, this is exactly my point and my intent...

I very much want to highlight the following sentences from this PR's opening thread: > This phase's purpose would be to allow the configuration of NGINX/ngx_lua with Lua scripts. This...

This PR reminds me a lot of #1577 which wasn't accepted, alas.

@dylanplecki Since so many efforts have been invested into optimizing OpenResty's [LuaJIT fork](https://github.com/openresty/luajit2) for OpenResty's use-cases, it is highly advised to run one of the formal [OpenResty releases](https://openresty.org/en/download.html). It is...

It seems I should have asked this question in #1661 instead.

`:get()` now already has other return values. We should follow the `lua_shared_dict` API and implement this as a standalone `:ttl()` method (i.e. [ngx.shared.DICT.ttl](https://github.com/openresty/lua-nginx-module#ngxshareddictttl)).

+1, this makes the library hard to use. I am surprised that it can handle sparse arrays but not empty ones? Or am I missing something? @kikito's solution seems to...