Initialize the Support Function Table of a process level ScriptBasic program object to be inherited by other program objects. If you read it first time, read on until you understand what this function really does and rather how to use it!
This is going to be a bit long, but you better read it along with the documentation of the function @xref{scriba_InheritModuleInterface()}.
This function is needed only for programs that are
You most probably know that modules can access system and ScriptBasic fucntions via a call-back table. That is a huge struct containing pointers to the functions that ScriptBasic implements. This is the ST (aka support table).
This helps module writers to write system independent code as well as to access ScriptBasic functions easily. On the other hand modules are also free to alter this table and because many functions, tough not all are called via this table by ScriptBasic itself a module may alter the core behavior of ScriptBasic.
For this reason each interpreter has its own copy of ST. This means that if an interpreter alters the table it has no effect on another interpreter running in the same process in anther thread.
This is fine so far. How about modules that run asynchronous threads? For example the very first interpter thread that uses the module mt starts in the initialization a thread that later deletes all sessions that time out. This thread lives a long life.
The thread that starts the worker thread is an interpreter thread and has its own copy of the ST. The thread started asynchronous however should not use this ST because the table is purged from memory when the interpreter instance it blelonged to finishes.
To have ST for worker threads there is a need for a program object that is not purged from memory so long as long the process is alive. Fortunately there is such an object: the configuration program object. Configuration is usually read only once by multi-thread implementations and the same configuration information is shared by the serveral threads. The same way the several program objects may share a ST.
The difference is that configuration is NOT altered by the interpreter or by any module in any way but ST may. Thus each execution object has two pointers: pST and pSTI. While pST points to the support table that belongs to the interpreter instance the secondpointer pSTI points to a ST that is global for the whole process and is permanent. This ST is to be used by worker threads and should not be altered by the module without really good reason.
Thus: Don't call this function for normal program objects! For usualy program objects module interface is automatically initialized when the first module function is called. Call this function to initialize a ST for a pseudo program object that is never executed but rather used to inherit this ST for worker threads.
int scriba_InitModuleInterface(pSbProgram pProgram
){