OScript Globals

Alexey_Ovchinnikov

Hi,

I am trying to understand how $$ globals work. OScript language reference says:
"$ is used to access globals that are visible to the entire application, while $$ globals are visible only to the current thread."
https://knowledge.opentext.com/knowledge/llisapi.dll/fetch/2001/15080935/-15106263/15106294/15106295/16376487/42329092/oscript/behaviour.html

What does it mean "visible only to a current thread" and "visible to the entire application"?
I thought oscript code executes inside OscriptVM sandbox and there is no connection to other OscriptVMs. So every $ variable is visible inside current OScriptVM (and inside only current thread).

But it sounds like $ globals can cross those boundaries and should be visible from other threads/OscriptVMs.

Mark_Sherry

I think the first thing to understand is that in OScript, a thread is not necessarily a thread. OScript was originally developed for an OS without true preemptive multithreading, so they wrote their own green thread implementation. These days OScript uses real threads as well, on top of the green threads.

Where the documentation refers to the application, it actually means an OS-level thread. Each of these threads has its own copy of the OSpaces loaded, and its own $ global variables. If you have 8 threads loaded, they are essentially running 8 separate instances of the Content Server application. If you had an init script that made a virtual coin flip and deleted every object it could find on a result of 'tails', every other request would result in a stack trace, but the other requests would go through fine - they all have their own idea of what's in the OSpace. (Of course, if you did this with OSpaces unlocked, you'd be in a world of hurt the next time you restarted.)

Where the documentation refers to a thread (in this, and a few other cases), it's referring to one of the green threads. These threads are created every time the C++ code needs to run some OScript. Examples of when this happens include when a request is being served, and when a callback is being made from, e.g. a DAPI call. I'll refer to these threads as "Execution Contexts" in hopes that that will lead to a bit less confusion. $$ globals are visible only within the Execution Context they were defined, which is why they're not visible from within DAPI callbacks.

That a DAPI callback is also a separate 'thread' is also why setting breakpoints in them leads to disappointing results - when the callback's 'thread' hits the breakpoint and pauses, the scheduler looks for the next 'thread' to run, and finds the thread that triggered the callback. It carries on execution, but without having gotten a proper return value from the built-in it was trying to call, since it's waiting on the now-blocked callback 'thread'.

In short, each OS thread is running its own CS application, each of which has is own $globals; and each of those threads runs multiple 'threads', usually in sequence, to execute OScript code, and each of those has its own $$globals.