Threads

Elzed does not create threads for its own use. This was a fundamental design choice, recognizing that Elzed is a library, not an application, and therefore that thread creation and management should be left entirely in your hands.

Elzed is, however, designed to be thread safe. Thread safety is achieved through the use of contexts. A context can be thought of as a walled-off workspace; the global data within a context cannot be affected by any other context. By assigning each thread its own context, you are assured that each thread's data is safe from interference from other threads. Create contexts with lzCreatePublicContext and lzCreatePrivateContext. Assign a context to a thread with lzSetContext.

Note that Elzed can still be used in a manner that is not thread safe. For example, data at cosmic scope is available at all times to all contexts. It is entirely possible for threads to interfere with each other through data at cosmic scope.

In addition, Elzed does not automatically assign each thread its own context. If you take no other action, each thread will operate within the primary context. Allowing multiple threads to simultaneously operate in the same context, either the primary or one you have created, is not thread safe. If you choose to operate in this mode, you will either have to accept the risk of cross-thread interference, or you'll have to take steps in your code to control each thread's access to the shared context.

Why would we ship Elzed with potentially hazardous operational modes? It's the result of a design trade-off between safety and flexibility. By placing thread and context management in your hands, it's possible to use them in creative and useful ways. For example, you could use a small pool of contexts to service a large number of threads, or assign multiple contexts to a single thread.