is multithreading possible in rhino?

[newbiecoder66]

Hi I'm trying to execute one JS Rhino script before another inside of another application (Cameo/MagicDraw), so I'm experimenting with asynchronous programming and multithreading. Is this supported by rhino?
I know it's possible in Java if you specify a shared object and calling synchronized(object) {//thread body} and inside have the waiting thread call .wait() and the worker thread call .notify() so that I can run worker thread/file before the waiting thread/file. However rhino seems to not recognize the synchronized() keyword and syntax.
Any help would be greatly appreciated and I'm open to other ideas on how I can specify one script to run before another (because I need values and calculations performed in 1 script in the other script) maybe this is a longer way to achieve this.

[p-bakker]

Hi, don't have a clearcut answer for you, but:

• latest versions of Rhino do support promises
• Javascript code inside Rhino runs within a Context, which is tied to Thread
• depending on how you use Rhino, you may have direct access to Java, which with allow you to interact with any threading-related Java API
• while Javascript doesn't have a synchronized keyword, Rhino does have an Synchronized class, which, if accessible inside Javascript, can be used to make methods synchronize on their this, see https://www-archive.mozilla.org/rhino/apidocs/org/mozilla/javascript/synchronizer (exposed in the shell by default as sync
• JavaScript objects themselves are NOT fully thread safe, see Fixed deadlock when sealing objects with a LazyCtor #1476 (comment) for some more info

Hope this provides some useful info

[gbrail]

Thanks for your answer, Paul. This is in the category of "we should write some documentation for this." JavaScript (the language) doesn't really contemplate multi-threading, and almost every JavaScript engine operates under the assumption that everything is single-threaded. (Contrast this to Java, Go, Rust, etc which have an explicit part of the specification that talks about how things are supposed to work across threads.) Over the years, people have written multi-threaded Java programs in Rhino, which is why it has, for example, a "synchronized" keyword available as an extension, but in general I don't think that what's there is really thread-safe in all cases. My official advice for multi-threading in Rhino is to ensure that each script operates in one thread at a time. That means not to run a script and then try to execute multiple functions at the same time in different threads, for example. However, you can have as many separate scripts running in a multi-threaded process as you'd like, as long as each individual script is kept single-threaded. That's by far the safest way and the only one that I can be assured is thread safe in all cases.

…

On Wed, Jun 19, 2024 at 10:15 AM Paul Bakker ***@***.***> wrote: Hi, don't have a clearcut answer for you, but: - latest versions of Rhino do support promises - Javascript code inside Rhino runs within a Context, which is tied to Thread - depending on how you use Rhino, you may have direct access to Java, which with allow you to interact with any threading-related Java API - while Javascript doesn't have a synchronized keyword, Rhino does have an Synchronized class, which, if accessible inside Javascript, can be used to make methods synchronize on their this, see https://www-archive.mozilla.org/rhino/apidocs/org/mozilla/javascript/synchronizer (exposed in the shell by default as sync - JavaScript objects themselves are NOT fully thread safe, see #1476 (comment) <#1476 (comment)> for some more info Hope this provides some useful info — Reply to this email directly, view it on GitHub <#1496 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAD7I24HQHNHKRKONFE2LYTZIG4C7AVCNFSM6AAAAABJQYYDZOVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TQMRQGMYDA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[p-bakker]

This is in the category of "we should write
some documentation for this."

Agreed, hence I had already added the docs label to it, to find this discussion once we get to enhance our docs... 🙂

Any chance you could elaborate a bit on your knowledge on what we do have wrt mutlithreading support? From the linked PR discussion it sounds like adding/removing properties on objects is threadsafe, but mutating a property value isn't? Or am I completely misreading that discussion?

[p-bakker]

Context.FEATURE_THREAD_SAFE_OBJECTS should be part of discussing/documenting multi-threading support I think

[tonygermano]

I'd just like to throw this into the mix: https://rhino.github.io/tutorials/scripting_java/#javascript-functions-as-java-interfaces

js> t = java.lang.Thread(function () { print("\nrunning"); });
Thread[Thread-0,5,main]
js> t.start()
js>
running

I've recently been experimenting with using the async methods of java.http.net.HttpClient from Rhino, and I'm using javascript arrow functions to implement the functional interfaces from the CompletableFuture API to handle the responses.

It seems to be working, but I'm programming in a functional style, so I'm usually not accessing the same javascript objects from multiple threads. If I do need to share something between threads, then I would use something from java.util.concurrent rather than javascript objects.

[tonygermano]

I recall doing some testing many years ago after reading that snippet from the Scripting Java doc above. I'm fairly certain that when you create a new thread in that manner from javascript that a new Context is automatically created for the pieces of javascript code running the new thread. That's probably even more of a reason to make sure that if you are sharing objects between threads/contexts to make sure they are thread-safe java objects.

[p-bakker]

A (new) Context is indeed automatically associated with a Thread if attempting to execute some JavaScript with Rhino in a thread that doesn't yet have Context associated with it

That's the core of the archetypical webserver demo implementation, where the Java server starts a thread for each incoming HttpRequest and you can just handle that request in Rhino without having to think much about threading and contexts.

No expert here on threading (in Java), but I think that threading issues mainly arise when state of 'objects' shared between threads is modified, in which case synchronization/locking is required. If all threads just operate on their own 'state', all should be fine

Rhino has special features to help scale in a multi-threaded scenario: it's possible to set up Rhino to use a shared (and potentially sealed) top-level scope. The top-level scope is the one holding all standard JavaScript 'objects' like Math, Array, Object etc. By sharing this top level scope between multiple threads, the overhead of having to instantiate all these standard objects over and over again is removed. However, when shared between threads, you open yourself up for both threading issues and security issues, but through sealing the scope both these ought to be prevented

For more info on this topic see https://rhino.github.io/docs/scopes_and_contexts/#sealed-shared-scopes and also
#1085

Again: no expert here, this is all just my understanding, so please correct me if I'm wrong 🙂