Question

I would like to know if DWScript is capable of using threads inside of scripts, as some engines do not synchronize access to it’s internal data structures.

Answer 1

Arnaud gave the key points:

• each compiler instance can only be invoked from one thread at a time. You can have multiple compiler instances invoked in multiple threads at the same time, and a particular compiler instance can be used from multiple threads, provided only one thread uses it a time.
• each compiled program can have multiple executions, each execution can be running in its own thread. Also a particular execution can be used by several threads, provided only one thread uses it at a time.
• each executions has its own space for its variables, and its own stack, object instances are on the heap and can technically be shared across executions, there is no locking mechanism for that, but you could make your own.
• the script engine does not perform any synchronization or locking when using classes or functions exposed to it (be it via TdwsUnit, RTTI, etc.), so when running script executions in threads, make sure you only exposed thread-safe stuff (be particularly careful about that for RTTI, since lot of the RTL & VCL is not thread-safe to begin with)

Running multiple executions of a script is similar to having multiple threads in Delphi, though each new execution has not only its own stack (like Delphi threads) but also its own variable space (in Delphi it would be a bit like if you had “thread var” everywhere). And DWScript executions don’t have to be in their own thread, they can be moved across threads, or polled and used in a lower number of threads (the only limitation being that each execution is used by only one thread at a time, as mentioned above).

So nothing prevents you from exposing a function that would spawn a thread (and corresponding execution) in a script function, but communication across the executions wouldn’t be via shared variables (like you could be tempted to do in Delphi), but would have to go through your own exposed functions (or external variables), return values (using an “evaluate” approach, cf. the unit tests), “shared” object instances, or “global vars”.

By “global vars”, I mean the functions defined in dwsGlobalVarsFunctions.pas, which can be used for inter-execution data exchange. To activate them, just have a “uses dwsGlobalVarsFunctions” somewhere in your project.

They expose a set of Read/WriteGlobalVar functions, which allow storing and retrieving named variants across all script executions running within the same Delphi process, and those reads & writes are “atomic” from a threading point of view.