summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorBenoit Germain <bnt.germain@gmail.com>2021-06-16 18:41:14 +0200
committerBenoit Germain <bnt.germain@gmail.com>2021-06-16 18:41:14 +0200
commit75af99d334462f2258b15cf56db931d81eb3279b (patch)
treee4e1a1a0027704c99b8fbc70923b0f313132f93b
parent73cb06d3f482d2f9ac7ab7002c1b5f01bfc3add6 (diff)
downloadlanes-75af99d334462f2258b15cf56db931d81eb3279b.tar.gz
lanes-75af99d334462f2258b15cf56db931d81eb3279b.tar.bz2
lanes-75af99d334462f2258b15cf56db931d81eb3279b.zip
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.
-rw-r--r--index.html38
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 @@
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>
1581int luaopen_deep_test(lua_State* L) 1581int 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>