codecov[bot]
commented
4 months ago Codecov Report
Attention: Patch coverage is 89.11392% with 43 lines in your changes are missing coverage. Please review.
Project coverage is 90.45255%. Comparing base (
b19d405) to head (8fd1fcb).
thibaultcha
Major refactor of the Lua bridge to support multiple concurrent yielding Lua threads. The old implementation would break down when scheduling more than one yielding Lua thread at a time.
The new implementation "tricks" OpenResty by scheduling uthreads via C and passing these threads to the OpenResty runloop as if they were created from Lua (via
ngx.thread). Because all uthreads must resume their "parent thread" when finished (as per OpenResty's implementation), we schedule a stub "entry thread" whenever we are trying to use the Lua bridge. This entry thread itself does nothing and is collected at request pool cleanup.List of significant changes for this refactor:
proxy_wasm.start()FFI function is removed. Onlyproxy_wasm.attach()is now necessary, and the filter chain is only resumed once the ngx_http_wasm_modulerewriteoraccessphases are entered. Prior,proxy_wasm.start()would resume the filter chain during the ngx_http_lua_module phase handlers, which was incompatible with Lua threads yielding.sock->envmember is now a pointer to the request'senvinstead of a copy so as to manipulate theenv->statecontrol variable.wasm_calldirective can now yield, which allows for sanity testing of the Lua bridge yielding functionality.rctx->resume_handlerpointer holds the resume entry point back from yielding facilities intongx_http_core_run_phases. For now, only the Lua bridge uses it, but other yielding facilities should be refactored to use it so as to factorize our resuming code.Fix https://github.com/Kong/ngx_wasm_module/issues/524