diff options
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 |
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.html | 38 |
1 files changed, 19 insertions, 19 deletions
@@ -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> |