From adaa36dbec1ce9aaafd61873b9d3d898a8c240cf Mon Sep 17 00:00:00 2001 From: Benoit Germain Date: Thu, 11 Apr 2024 15:14:52 +0200 Subject: Bring all interesting fixes from the C++ implementation back into the C implementation --- docs/index.html | 24 ++++++++++++++++++------ 1 file changed, 18 insertions(+), 6 deletions(-) (limited to 'docs') diff --git a/docs/index.html b/docs/index.html index aed022a..da94898 100644 --- a/docs/index.html +++ b/docs/index.html @@ -70,7 +70,7 @@

- This document was revised on 23-Feb-24, and applies to version 3.16.3. + This document was revised on 11-Apr-24, and applies to version 3.17.0.

@@ -290,6 +290,19 @@ + + + .keepers_gc_threshold + + integer + + (Since v3.17.0)
+ If <0, GC runs automatically. This is the default.
+ If 0, GC runs after *every* keeper operation.
+ If >0, Keepers run GC manually with lua_gc(LUA_GCCOLLECT) whenever memory usage reported by lua_gc(LUA_GCCOUNT) reaches this threshold. Check is made after every keeper operation (see below). If memory usage remains above threshold after the GC cycle, an error is raised. + + + .with_timers @@ -351,7 +364,6 @@ The contents will be used to create the state with lua_newstate( allocF, allocUD). This option is mostly useful for embedders that want to provide different allocators to each lane, for example to have each one work in a different memory pool thus preventing the need for the allocator itself to be threadsafe. - Note however that linda deep proxy are allocated with the allocator from the master state, because they are not tied to a particular state. @@ -364,7 +376,7 @@ (Since v3.16.1)
- Controls which allocator is used for Lanest internal allocations (for keeper and deep userdata management). + Controls which allocator is used for Lanes internal allocations (for keeper, linda and lane management). If "libc", Lanes uses realloc and free.
If "allocator", Lanes uses whatever was obtained from the "allocator" setting.
This option is mostly useful for embedders that want control all memory allocations, but have issues when Lanes tries to use the Lua State allocator for internal purposes (especially with LuaJIT). @@ -911,7 +923,7 @@
- 
	{{name = "name", status = "status", ...}|nil = lanes.threads()
+ 
	{name = "name", status = "status", ...}|nil = lanes.threads()
@@ -1617,8 +1629,8 @@ events to a common Linda, but... :).

Clonable full userdata in your own apps

Starting with version 3.13.0, a new way of passing full userdata across lanes uses a new __lanesclone metamethod. - When a deep userdata is cloned, Lanes calls __lanesclone once, in the context of the source lane.
- The call receives the clone and original as light userdata, plus the actual userdata size, as in clone:__lanesclone(original,size), and should perform the actual cloning.
+ When a deep userdata is cloned, Lanes calls __lanesclone once, in the context of the source lane.
+ The call receives the clone and original as light userdata, plus the actual userdata size, as in clone:__lanesclone(original,size), and should perform the actual cloning.
A typical implementation would look like (BEWARE, THIS CHANGED WITH VERSION 3.16.0): 
 static int clonable_lanesclone( lua_State* L)
-- 
cgit v1.2.3-55-g6feb