can be configured to act as a facade for multiple
(or really multiple Ruby VMs, since each
instance is a Ruby "VM"), and this enum controls
that behaviour. (this behaviour is bit like that of
— it changes its behaviour
silently depending on the calling thread, an act of multiplexing.)
When you think of this multiplexing behaviour, there are two sets of states that need separate attention.
instance, which represents the whole VM, classes, global variables, etc. Then
there's attributes and so-called
variables, which are really a special scope induced by the
scripting container for better JSR-223 interop.
In this documentation, we refer to the former as "the runtime" and the latter as "the variables",
but the variables shouldn't be confused with the global variables in Ruby's semantics, which belongs
to the runtime.
s that are created with this scope will share a single
runtime and a single set of variables. Therefore one container can
set a value and another container will see the same value.
will not do any multiplexing at all.
will get one runtime and one set of variables, and regardless of the calling
thread it'll use this same pair.
If you have multiple threads calling single
then you may need to take caution as a variable set by one thread will be visible to another thread.
If you aren't using the variables of
, this is normally what you want.
Known as the "apartment thread model", this mode makes
creates a runtime and a variable map separately for each calling thread. Therefore, despite
the fact that multiple threads call on the same object, they are completely isolated from each other.
(the flip side of the coin is that no ruby objects can be shared between threads as they belong
to different "ruby VM".)
In this mode, there'll be a single runtime dedicated for each
but a separate map of variables are created for each calling thread through
In a situation where you have multiple threads calling one
, this means
ruby code will see multiple threads calling them, and therefore they need to be thread safe.
But because variables are thread local, if your program does something like (1) set a few variables,
(2) evaluate a script that refers to those variables, then you won't have to worry about values from
multiple threads mixing with each other.