clarify that states are per-thread

diff --git a/builder b/builder
index 4f5ab935098ebacd6b55e89b405bd69e80ab2baf..6176c5f68354ca82814ef20a4c87327785157ff3 160000 (submodule)
--- 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 6f23cfed173bfabb7fe8730f50a6ffb8c04778b7..08dab784054fd98a3de849c153617a515d3f281c 100644 (file)
--- 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``.