From 0d3b030eb92657dc276a6188f61e5cfdd7e265cb Mon Sep 17 00:00:00 2001 From: Benoit Germain Date: Mon, 27 May 2024 16:30:26 +0200 Subject: Optional Decoda support (disabled by default) --- docs/index.html | 20 +++++++++++--------- 1 file changed, 11 insertions(+), 9 deletions(-) (limited to 'docs') diff --git a/docs/index.html b/docs/index.html index 92cc38a..f5a074f 100644 --- a/docs/index.html +++ b/docs/index.html @@ -183,7 +183,7 @@

- luaopen_lanes_embedded leaves the module table on the stack. lanes.configure() must still be called in order to use Lanes. + luaopen_lanes_embedded leaves the module table on the stack. lanes.configure() must still be called in order to use Lanes.
If _luaopen_lanes is nullptr, a default loader will simply attempt the equivalent of luaL_dofile(L, "lanes.lua").

@@ -249,17 +249,17 @@ Requiring the module follows Lua 5.2+ rules: the module is not available under the global name "lanes", but has to be accessed through require's return value.

- After lanes is required, it is necessary to call lanes.configure(), which is the only function exposed by the module at this point. Calling configure() will perform one-time initializations and make the rest of the API available. + After lanes is required, it is necessary to call lanes.configure(), which is the only function exposed by the module at this point. Calling lanes.configure() will perform one-time initializations and make the rest of the API available.

- At the same time, configure() itself will be replaced by another function that raises an error if called again with differing arguments, if any. + At the same time, lanes.configure() itself will be replaced by another function that raises an error if called again with differing arguments, if any.

Also, once Lanes is initialized, require() is replaced by another one that wraps it inside a mutex, both in the main state and in all created lanes. This prevents multiple thread-unsafe module initializations from several lanes to occur simultaneously. It remains to be seen whether this is actually useful or not: If a module is already threadsafe, protecting its initialization isn't useful. And if it is not, any parallel operation may crash without Lanes being able to do anything about it.

- IMPORTANT NOTE: Only the first occurence of require "lanes" must be followed by a call to .configure(). From this point, a simple require "lanes" will do wherever you need to require lanes again. + IMPORTANT NOTE: Only the first occurence of require "lanes" must be followed by a call to lanes.configure(). From this point, a simple require "lanes" will be enough wherever you need to require lanes again.

@@ -758,8 +758,10 @@

- Each lane also gets a global function set_debug_threadname() that it can use anytime to do as the name says. Supported debuggers are Microsoft Visual Studio (for the C side) and Decoda (for the Lua side). -
+ Each lane gets a global function set_debug_threadname() that it can use anytime to do as the name says. Supported debuggers are Microsoft Visual Studio (for the C side) and Decoda (for the Lua side).
+ Decoda support is limited to setting a special global variable decoda_name. This is disabled by default. Change HAVE_DECODA_NAME() in lanesconf.h if necessary.
+ The name is stored inside the Lua state registry so that it is available for error reporting. Changing decoda_name doesn't affect this hidden name or the OS thread name reported by MSVC.
+ When Lanes is initialized by the first lanes.configure() call, "main" is stored in the registry in the same fashion (but decoda_name and the OS thread name are left unchanged).
The lane also has a method lane:get_debug_threadname() that gives access to that name from the caller side (returns "<unnamed>" if unset, "<closed>" if the internal Lua state is closed).

@@ -1334,7 +1336,7 @@
  • Performance. Changing any slot in a Linda causes all pending threads for that Linda to be momentarily awakened (at least in the C level). - This can degrade performance due to unnecessary OS level context switches. The more keeper states you declared with lanes.configure() the less this should be a problem. + This can degrade performance due to unnecessary OS level context switches. The more keeper states you declared with lanes.configure() the less this should be a problem.
    • @@ -1356,7 +1358,7 @@ events to a common Linda, but... :).

    - Timers are implemented as a lane. They can be enabled by setting "with_timers" to true in lanes.configure() settings. + Timers are implemented as a lane. They can be enabled by setting "with_timers" to true in lanes.configure() settings.

    @@ -1373,7 +1375,7 @@ events to a common Linda, but... :). 
     	local lanes = require "lanes"
-	lanes.configure()
+	lanes.configure{with_timers = true}
 
 	local linda = lanes.linda()
 
-- 
cgit v1.2.3-55-g6feb