From ca8c94836f9b711d16b0ad3e1867e2ca1d8c61ee Mon Sep 17 00:00:00 2001 From: Peter van Dijk Date: Wed, 17 Jul 2019 19:20:29 +0200 Subject: [PATCH] clarify that states are per-thread --- builder | 2 +- docs/lua-records/index.rst | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/builder b/builder index 4f5ab9350..6176c5f68 160000 --- a/builder +++ b/builder @@ -1 +1 @@ -Subproject commit 4f5ab935098ebacd6b55e89b405bd69e80ab2baf +Subproject commit 6176c5f68354ca82814ef20a4c87327785157ff3 diff --git a/docs/lua-records/index.rst b/docs/lua-records/index.rst index 6f23cfed1..08dab7840 100644 --- a/docs/lua-records/index.rst +++ b/docs/lua-records/index.rst @@ -206,6 +206,7 @@ The default mode of operation for LUA records is to create a fresh Lua state for This way, different LUA records cannot accidentally interfere with each other, by leaving around global objects, or perhaps even deleting relevant functions. However, creating a Lua state (and registering all our functions for it, see Reference below) takes measurable time. For users that are confident they can write Lua scripts that will not interfere with eachother, a mode is supported where Lua states are created on the first query, and then reused forever. +Note that the state is per-thread, so while data sharing between LUA invocations is possible (useful for caching and reducing the cost of ``require``), there is not a single shared Lua environment. In non-scientific testing this has yielded up to 10x QPS increases. To use this mode, set ``enable-lua-records=shared``. -- 2.50.1