From 5875fe44ba7a240dd101f954c7dc83337a0c2cef Mon Sep 17 00:00:00 2001 From: Benoit Germain Date: Wed, 16 Jun 2021 18:41:14 +0200 Subject: changed lanes.threads() output so that several lanes with the same name don't clobber each other in the result table In the original implementations, the debug name was used as key, which meant that several lanes using the same name would cause only the oldest non-collected one to be listed in the results. Now the result is an array of tuples. --- docs/index.html | 38 +++++++++++++++++++------------------- 1 file changed, 19 insertions(+), 19 deletions(-) (limited to 'docs') diff --git a/docs/index.html b/docs/index.html index 0b19223..49b862f 100644 --- a/docs/index.html +++ b/docs/index.html @@ -1,6 +1,6 @@ @@ -85,13 +85,13 @@ Lua Lanes is a Lua extension library providing the possibility to run multiple Lua states in parallel. It is intended to be used for optimizing performance on multicore CPU's and to study ways to make Lua programs naturally parallel to begin with.

- Lanes is included into your software by the regular require "lanes" method. No C side programming is needed; all APIs are Lua side, and most existing extension modules should work seamlessly together with the multiple lanes. + Lanes is included into your software by the regular require "lanes" method. No C side programming is needed; all APIs are Lua side, and most existing extension modules should work seamlessly together with the multiple lanes.

- Starting with version 3.1.6, Lanes should build and run identically with either Lua 5.1 or Lua 5.2. Version 3.10.0 supports Lua 5.3. + Starting with version 3.1.6, Lanes should build and run identically with either Lua 5.1 or Lua 5.2. Version 3.10.0 supports Lua 5.3.

- See comparison of Lua Lanes with other Lua multithreading solutions. + See comparison of Lua Lanes with other Lua multithreading solutions.

Features:

@@ -134,11 +134,11 @@
  • Openwrt (15.05 and later)
  • Windows 2000/XP and later (MinGW or Visual C++ 2005/2008)
    • - +

    @@ -843,7 +843,7 @@
    - 
    	{}|nil = lanes.threads()
    + 
    	{{name = "name", status = "status", ...}|nil = lanes.threads()
    @@ -851,7 +851,7 @@

    Only available if lane tracking feature is compiled (see HAVE_LANE_TRACKING in lanes.c) and track_lanes is set.
    - Returns a table where keys are a lane's name and values are the lane's status. Returns nil if no lane is running. + Returns an array table where each entry is a table containing a lane's name and status. Returns nil if no lane is running.

    @@ -891,7 +891,7 @@

    - stack_tbl is a table describing where the error was thrown. +stack_tbl is a table describing where the error was thrown.
    In "extended" mode, stack_tbl is an array of tables containing info gathered with lua_getinfo() ("source","currentline","name","namewhat","what").
    @@ -1434,7 +1434,7 @@ events to a common Linda, but... :).

  • Coroutines cannot be passed. A coroutine's Lua state is tied to the Lua state that created it, and there is no way the mixed C/Lua stack of a coroutine can be transfered from one Lua state to another.
    • -
  • Starting with version 3.10.1, if the metatable contains __lanesignore, the object is skipped and nil is transfered instead.
    • +
  • Starting with version 3.10.1, if the metatable contains __lanesignore, the object is skipped and nil is transfered instead.

    • @@ -1575,7 +1575,7 @@ static int clonable_lanesclone( lua_State* L)

    - NOTE: In the event the source userdata has uservalues, it is not necessary to create them for the clone, Lanes will handle their cloning.
    + NOTE: In the event the source userdata has uservalues, it is not necessary to create them for the clone, Lanes will handle their cloning.
    Of course, more complex objects may require smarter cloning behavior than a simple memcpy. Also, the module initialisation code should make each metatable accessible from the module table itself as in: 
     int luaopen_deep_test(lua_State* L)
@@ -1645,13 +1645,13 @@ int luaD_new_clonable( lua_State* L)
 
    
 
 
    
-    Deep userdata in transit inside keeper states (sent in a linda but not yet consumed) don't call idfunc(eDO_delete) and aren't considered by reference counting. The rationale is the following:
-    
    
-    If some non-keeper state holds a deep userdata for some deep object, then even if the keeper collects its own deep userdata, it shouldn't be cleaned up since the refcount is not 0.
-    
    
-    OTOH, if a keeper state holds the last deep userdata for some deep object, then no lane can do actual work with it. Deep userdata's idfunc() is never called from a keeper state.
-    
    
-    Therefore, Lanes can just call idfunc(eDO_delete) when the last non-keeper-held deep userdata is collected, as long as it doesn't do the same in a keeper state after that, since any remaining deep userdata in keeper states now hold stale pointers.
+	Deep userdata in transit inside keeper states (sent in a linda but not yet consumed) don't call idfunc(eDO_delete) and aren't considered by reference counting. The rationale is the following:
+	
    
+	If some non-keeper state holds a deep userdata for some deep object, then even if the keeper collects its own deep userdata, it shouldn't be cleaned up since the refcount is not 0.
+	
    
+	OTOH, if a keeper state holds the last deep userdata for some deep object, then no lane can do actual work with it. Deep userdata's idfunc() is never called from a keeper state.
+	
    
+	Therefore, Lanes can just call idfunc(eDO_delete) when the last non-keeper-held deep userdata is collected, as long as it doesn't do the same in a keeper state after that, since any remaining deep userdata in keeper states now hold stale pointers.
 
    
 
 
    
-- 
cgit v1.2.3-55-g6feb