You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi, i would like to use Nil.JS for making application logic scriptable in a web application (asp.net mvc).
And here i've got a design question - how to manage the Nil.JS context instances. I want to have a separate script runtime context for each executing web request, so the scripts can execute independently. But at the same time i have some variables, functions and libraries that are common to all these scripts and could be shared between them - something like a global context for the application scripts.
Here i'm not sure if i can have one global context for the entire application and only create child contexts per each request, or if i should have separate global context for each executing thread. What happens if child context from multiple threads access the same global context?
My motivation for a shared global context is mostly performance - it requires some time to parse all the libraries and global/shared code so i'd like to avoid doing that for every request.
So what do you recommend - one shared global context, or one global context per thread, or maybe some pool of reusable global contexts that get assigned to a single thread at a time and then returned to the pool?
Thanks
RG
The text was updated successfully, but these errors were encountered:
HI! Thanks for choosing this library.
One GlobalContext for everything is ok. All Contexts built on StringMap, which have some synchronization mechanisms (two lock in code ¯\_(ツ)_/¯). I previously received feedback about using in this scenario and fixed some bugs.
But do no use one instance of Script in more then one thread in same time. In other words Context is threadsafe, Script – not. And almost all classes of AST. You can make a pool of parsed Scripts for every js code you uses or parse every time before evaluation. This also applies to all functions, written in js. If your global objects contains such functions, you should wrap it into C# function with parsing or pool of instances.
Hi, i would like to use Nil.JS for making application logic scriptable in a web application (asp.net mvc).
And here i've got a design question - how to manage the Nil.JS context instances. I want to have a separate script runtime context for each executing web request, so the scripts can execute independently. But at the same time i have some variables, functions and libraries that are common to all these scripts and could be shared between them - something like a global context for the application scripts.
Here i'm not sure if i can have one global context for the entire application and only create child contexts per each request, or if i should have separate global context for each executing thread. What happens if child context from multiple threads access the same global context?
My motivation for a shared global context is mostly performance - it requires some time to parse all the libraries and global/shared code so i'd like to avoid doing that for every request.
So what do you recommend - one shared global context, or one global context per thread, or maybe some pool of reusable global contexts that get assigned to a single thread at a time and then returned to the pool?
Thanks
RG
The text was updated successfully, but these errors were encountered: