SHARED SERVICESREAD-ONLY SHARED OBJECTS
ScriptEase supports one other sharing mechanism via the API call seShareReadObject. This call allows sharing ScriptEase objects across threads albeit with several limitations.
Object handles, i.e. seobjects, can be made sharable by passing them to the seShareReadObject api call. Once this is done, the handle can be used in any context and thus the object it refers to can be used in any context as well. Such handles no longer follow the usual ScriptEase lifetime rules. Such handles can only be created in the first ScriptEase context before any other contexts are created. These handles are valid until that context is destroyed.
A typical use for read-shared objects is to initialize a context using seCreateContext as normal. Whatever standard libraries are defined in your jseopt.h file are added to the context as normal. Any program-specific libraries are added in the context’s sePrepareContextFunc callback. The result is that all of the wrapper functions normally available to a script are initialized in that context’s global object. That global object is made read-shared so that many new contexts can be created and share the same set of wrapper functions without having to reinitialize them in each context. This saves considerable startup time and memory for each new context created.
With this method, new contexts are created passing the SE_OPT_NO_LIBRARIES option to seCreateContext. This is because the new contexts will be sharing the old libraries and do not need their own copy of the libraries created. Likewise, these new contexts do not add program-specific libraries during their sePrepareContextFunc callback, instead using the copies created by the first context. The _prototype member of the global object of each new context is assigned with the shared global object thus allowing all new contexts to see and share the original libraries.
The ScriptEase sample objshare does exactly what is described above.
Read-shared objects are completely read-only as are their children. No changes at all can be made to them; they cannot get new members, have members deleted, alter member values, or be modified in any way. This applies in all contexts including the first context that originally created the object.
The shared objects are cleaned up when the context creating them, the first context, is destroyed. This means object destructors will be called and library termination routines invoked. The first context can only be destroyed if there are no other contexts sharing its objects. If you have shared any objects then a call to seDestroyContext on the first context will fail with an appropriate api error if there are any other contexts still undestroyed.