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.
author: Benoit Germain <bnt.germain@gmail.com> 2021-06-16 18:41:14 +0200
committer: Benoit Germain <bnt.germain@gmail.com> 2021-06-16 18:41:14 +0200
commit: 75af99d334462f2258b15cf56db931d81eb3279b (patch)
tree: e4e1a1a0027704c99b8fbc70923b0f313132f93b
parent: 73cb06d3f482d2f9ac7ab7002c1b5f01bfc3add6 (diff)
download: lanes-75af99d334462f2258b15cf56db931d81eb3279b.tar.gz
lanes-75af99d334462f2258b15cf56db931d81eb3279b.tar.bz2
lanes-75af99d334462f2258b15cf56db931d81eb3279b.zip
1 files changed, 19 insertions, 19 deletions
diff --git a/index.html b/index.html
index 0b19223..49b862f 100644
--- a/index.html
+++ b/index.html
@@ -1,6 +1,6 @@
 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
 <!--
-    Documentation for Lua Lanes
+        Documentation for Lua Lanes
 -->
 <html>
@@ -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.
 </p>
 <p>
-    Lanes is included into your software by the regular <tt>require "lanes"</tt> 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 <tt>require "lanes"</tt> 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.
 </p>
 <p>
-  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.
 </p>
 <p>
-    See <A HREF="comparison.html">comparison</A> of Lua Lanes with other Lua multithreading solutions.
+        See <A HREF="comparison.html">comparison</A> of Lua Lanes with other Lua multithreading solutions.
 </p>
 <p>
        <h3>Features:</h3>
@@ -134,11 +134,11 @@
                <li>Openwrt (15.05 and later)</li>
                <li>Windows 2000/XP and later <font size="-1">(MinGW or Visual C++ 2005/2008)</font></li>
 <!--
-    Other OS'es here once people help test them. (and the tester's name)
+        Other OS'es here once people help test them. (and the tester's name)
-    Win64, BSD, Linux x64, Linux embedded, QNX, Solaris, ...
+        Win64, BSD, Linux x64, Linux embedded, QNX, Solaris, ...
 -->
-                </ul>
+        </ul>
 </p>
 <p>
@@ -843,7 +843,7 @@
        <table border="1" bgcolor="#E0E0FF" cellpadding="10" style="width:50%">
                <tr>
                        <td>
-                                <pre>   {}|nil = lanes.threads()</pre>
+                                <pre>   {{name = "name", status = "status", ...}|nil = lanes.threads()</pre>
                        </td>
                </tr>
        </table>
@@ -851,7 +851,7 @@
 <p>
        Only available if lane tracking feature is compiled (see <tt>HAVE_LANE_TRACKING</tt> in <tt>lanes.c</tt>) and <a href="#track_lanes"><tt>track_lanes</tt></a> is set.
        <br/>
-        Returns a table where keys are a lane's name and values are the lane's status. Returns <tt>nil</tt> if no lane is running.
+        Returns an array table where each entry is a table containing a lane's name and status. Returns <tt>nil</tt> if no lane is running.
 </p>
@@ -891,7 +891,7 @@
 </p>
 <p>
-  <tt>stack_tbl</tt> is a table describing where the error was thrown.
+<tt>stack_tbl</tt> is a table describing where the error was thrown.
        <br/>
  In <tt>"extended"</tt> mode, <tt>stack_tbl</tt> is an array of tables containing info gathered with <tt>lua_getinfo()</tt> (<tt>"source"</tt>,<tt>"currentline"</tt>,<tt>"name"</tt>,<tt>"namewhat"</tt>,<tt>"what"</tt>).
        <br/>
@@ -1434,7 +1434,7 @@ events to a common Linda, but... :).</font>
                        </ul>
                </li>
                <li>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.</li>
-        <li>Starting with version 3.10.1, if the metatable contains <tt>__lanesignore</tt>, the object is skipped and <tt>nil</tt> is transfered instead.</li>
+                <li>Starting with version 3.10.1, if the metatable contains <tt>__lanesignore</tt>, the object is skipped and <tt>nil</tt> is transfered instead.</li>
        </ul>
 </p>
@@ -1575,7 +1575,7 @@ static int clonable_lanesclone( lua_State* L)
 </p>
 <p>
-    <b>NOTE</b>: In the event the source userdata has uservalues, it is not necessary to create them for the clone, Lanes will handle their cloning.<br/>
+        <b>NOTE</b>: In the event the source userdata has uservalues, it is not necessary to create them for the clone, Lanes will handle their cloning.<br/>
        Of course, more complex objects may require smarter cloning behavior than a simple <tt>memcpy</tt>. Also, the module initialisation code should make each metatable accessible from the module table itself as in:
 <table border="1" bgcolor="#FFFFE0" cellpadding="10" style="width:50%"><tr><td><pre>
 int luaopen_deep_test(lua_State* L)
@@ -1645,13 +1645,13 @@ int luaD_new_clonable( lua_State* L)
 </p>
 <p>
-    Deep userdata in transit inside keeper states (sent in a linda but not yet consumed) don't call <tt>idfunc(eDO_delete)</tt> and aren't considered by reference counting. The rationale is the following:
+        Deep userdata in transit inside keeper states (sent in a linda but not yet consumed) don't call <tt>idfunc(eDO_delete)</tt> and aren't considered by reference counting. The rationale is the following:
-    <br />
+        <br />
-    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.
+        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.
-    <br />
+        <br />
-    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 <tt>idfunc()</tt> is never called from a keeper state.
+        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 <tt>idfunc()</tt> is never called from a keeper state.
-    <br />
+        <br />
-    Therefore, Lanes can just call <tt>idfunc(eDO_delete)</tt> 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.
+        Therefore, Lanes can just call <tt>idfunc(eDO_delete)</tt> 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.
 </p>
 <p>
author	Benoit Germain <bnt.germain@gmail.com>	2021-06-16 18:41:14 +0200
committer	Benoit Germain <bnt.germain@gmail.com>	2021-06-16 18:41:14 +0200
commit	75af99d334462f2258b15cf56db931d81eb3279b (patch)
tree	e4e1a1a0027704c99b8fbc70923b0f313132f93b
parent	73cb06d3f482d2f9ac7ab7002c1b5f01bfc3add6 (diff)
download	lanes-75af99d334462f2258b15cf56db931d81eb3279b.tar.gz lanes-75af99d334462f2258b15cf56db931d81eb3279b.tar.bz2 lanes-75af99d334462f2258b15cf56db931d81eb3279b.zip

diff --git a/index.html b/index.html index 0b19223..49b862f 100644 --- a/index.html +++ b/index.html
@@ -1,6 +1,6 @@
1	<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">	1	<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
2	<!--	2	<!--
3	Documentation for Lua Lanes	3	Documentation for Lua Lanes
4	-->	4	-->
5		5
6	<html>	6	<html>
@@ -85,13 +85,13 @@
85	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.	85	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.
86	</p>	86	</p>
87	<p>	87	<p>
88	Lanes is included into your software by the regular <tt>require "lanes"</tt> 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.	88	Lanes is included into your software by the regular <tt>require "lanes"</tt> 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.
89	</p>	89	</p>
90	<p>	90	<p>
91	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.	91	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.
92	</p>	92	</p>
93	<p>	93	<p>
94	See <A HREF="comparison.html">comparison</A> of Lua Lanes with other Lua multithreading solutions.	94	See <A HREF="comparison.html">comparison</A> of Lua Lanes with other Lua multithreading solutions.
95	</p>	95	</p>
96	<p>	96	<p>
97	<h3>Features:</h3>	97	<h3>Features:</h3>
@@ -134,11 +134,11 @@
134	<li>Openwrt (15.05 and later)</li>	134	<li>Openwrt (15.05 and later)</li>
135	<li>Windows 2000/XP and later <font size="-1">(MinGW or Visual C++ 2005/2008)</font></li>	135	<li>Windows 2000/XP and later <font size="-1">(MinGW or Visual C++ 2005/2008)</font></li>
136	<!--	136	<!--
137	Other OS'es here once people help test them. (and the tester's name)	137	Other OS'es here once people help test them. (and the tester's name)
138		138
139	Win64, BSD, Linux x64, Linux embedded, QNX, Solaris, ...	139	Win64, BSD, Linux x64, Linux embedded, QNX, Solaris, ...
140	-->	140	-->
141	</ul>	141	</ul>
142		142
143	</p>	143	</p>
144	<p>	144	<p>
@@ -843,7 +843,7 @@
843	<table border="1" bgcolor="#E0E0FF" cellpadding="10" style="width:50%">	843	<table border="1" bgcolor="#E0E0FF" cellpadding="10" style="width:50%">
844	<tr>	844	<tr>
845	<td>	845	<td>
846	<pre> {}\|nil = lanes.threads()</pre>	846	<pre> {{name = "name", status = "status", ...}\|nil = lanes.threads()</pre>
847	</td>	847	</td>
848	</tr>	848	</tr>
849	</table>	849	</table>
@@ -851,7 +851,7 @@
851	<p>	851	<p>
852	Only available if lane tracking feature is compiled (see <tt>HAVE_LANE_TRACKING</tt> in <tt>lanes.c</tt>) and <a href="#track_lanes"><tt>track_lanes</tt></a> is set.	852	Only available if lane tracking feature is compiled (see <tt>HAVE_LANE_TRACKING</tt> in <tt>lanes.c</tt>) and <a href="#track_lanes"><tt>track_lanes</tt></a> is set.
853	<br/>	853	<br/>
854	Returns a table where keys are a lane's name and values are the lane's status. Returns <tt>nil</tt> if no lane is running.	854	Returns an array table where each entry is a table containing a lane's name and status. Returns <tt>nil</tt> if no lane is running.
855	</p>	855	</p>
856		856
857		857
@@ -891,7 +891,7 @@
891	</p>	891	</p>
892		892
893	<p>	893	<p>
894	<tt>stack_tbl</tt> is a table describing where the error was thrown.	894	<tt>stack_tbl</tt> is a table describing where the error was thrown.
895	<br/>	895	<br/>
896	In <tt>"extended"</tt> mode, <tt>stack_tbl</tt> is an array of tables containing info gathered with <tt>lua_getinfo()</tt> (<tt>"source"</tt>,<tt>"currentline"</tt>,<tt>"name"</tt>,<tt>"namewhat"</tt>,<tt>"what"</tt>).	896	In <tt>"extended"</tt> mode, <tt>stack_tbl</tt> is an array of tables containing info gathered with <tt>lua_getinfo()</tt> (<tt>"source"</tt>,<tt>"currentline"</tt>,<tt>"name"</tt>,<tt>"namewhat"</tt>,<tt>"what"</tt>).
897	<br/>	897	<br/>
@@ -1434,7 +1434,7 @@ events to a common Linda, but... :).</font>
1434	</ul>	1434	</ul>
1435	</li>	1435	</li>
1436	<li>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.</li>	1436	<li>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.</li>
1437	<li>Starting with version 3.10.1, if the metatable contains <tt>__lanesignore</tt>, the object is skipped and <tt>nil</tt> is transfered instead.</li>	1437	<li>Starting with version 3.10.1, if the metatable contains <tt>__lanesignore</tt>, the object is skipped and <tt>nil</tt> is transfered instead.</li>
1438	</ul>	1438	</ul>
1439	</p>	1439	</p>
1440		1440
@@ -1575,7 +1575,7 @@ static int clonable_lanesclone( lua_State* L)
1575	</p>	1575	</p>
1576		1576
1577	<p>	1577	<p>
1578	<b>NOTE</b>: In the event the source userdata has uservalues, it is not necessary to create them for the clone, Lanes will handle their cloning.<br/>	1578	<b>NOTE</b>: In the event the source userdata has uservalues, it is not necessary to create them for the clone, Lanes will handle their cloning.<br/>
1579	Of course, more complex objects may require smarter cloning behavior than a simple <tt>memcpy</tt>. Also, the module initialisation code should make each metatable accessible from the module table itself as in:	1579	Of course, more complex objects may require smarter cloning behavior than a simple <tt>memcpy</tt>. Also, the module initialisation code should make each metatable accessible from the module table itself as in:
1580	<table border="1" bgcolor="#FFFFE0" cellpadding="10" style="width:50%"><tr><td><pre>	1580	<table border="1" bgcolor="#FFFFE0" cellpadding="10" style="width:50%"><tr><td><pre>
1581	int luaopen_deep_test(lua_State* L)	1581	int luaopen_deep_test(lua_State* L)
@@ -1645,13 +1645,13 @@ int luaD_new_clonable( lua_State* L)
1645	</p>	1645	</p>
1646		1646
1647	<p>	1647	<p>
1648	Deep userdata in transit inside keeper states (sent in a linda but not yet consumed) don't call <tt>idfunc(eDO_delete)</tt> and aren't considered by reference counting. The rationale is the following:	1648	Deep userdata in transit inside keeper states (sent in a linda but not yet consumed) don't call <tt>idfunc(eDO_delete)</tt> and aren't considered by reference counting. The rationale is the following:
1649	<br />	1649	<br />
1650	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.	1650	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.
1651	<br />	1651	<br />
1652	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 <tt>idfunc()</tt> is never called from a keeper state.	1652	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 <tt>idfunc()</tt> is never called from a keeper state.
1653	<br />	1653	<br />
1654	Therefore, Lanes can just call <tt>idfunc(eDO_delete)</tt> 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.	1654	Therefore, Lanes can just call <tt>idfunc(eDO_delete)</tt> 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.
1655	</p>	1655	</p>
1656		1656
1657	<p>	1657	<p>