Duktape supports a limited form of multithreading:
duk_create_heap()
is
single threaded: only one native thread can execute code in the heap at a
time. The native thread can change over time, as long as two native threads
are not active at the same time in the same Duktape heap.duk_suspend()
and later
resume it with duk_resume()
.
Between these calls another thread may call into the same Duktape heap.
Application code must manage any locking necessary to ensure only one
native thread calls into Duktape at a time.duk_suspend()
and
duk_resume()
API calls
(introduced in Duktape 1.6.0) allow a native thread to suspend while
another native thread executes calls into a Duktape heap.For some background, a Duktape heap is a single memory management region regardless of how many Duktape threads exist in the heap (don't confuse native threads and Duktape threads). Because the Duktape threads in a heap can share object references, multithreading support would need synchronization for garbage collection and all object handling. Synchronization would be a major portability issue, so a practical approach is to limit a Duktape heap to be single threaded. Duktape heaps don't share anything so there are no threading limitations between them as a general rule. However, when some platform features are not available (such as variadic preprocessor macros or re-entrant system calls) there are some limitations.
See threading.rst and How to use multiple native threads for a detailed discussion of threading limitations and best practices.