Jump to content
  • Advertisement
Sign in to follow this  
Rain Dog

Method for reusing script engines.

This topic is 4813 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Witchlord, How do you see fit for an application to have multiple threads executing seperate instances of a script engine? Currently I create a new instance of asIScriptEngine for each script I wish to execute, each executing in its own thread. The problem is that each engine is supposed to be exactly the same, so there is a great deal of overhead in configuring the engine each time a new script is desired. Is it safe to use one script engine and just be able to use asIScriptContext objects instead of a full blown seperate instantiation of engine+context?

Share this post


Link to post
Share on other sites
Advertisement
You've compiled the library with the preprocessor flag USE_THREADS defined, I hope.

I have tried to add at least minimal support for multithreading, however I cannot guarantee that it will work. It is definetely safer to use only one thread per engine, as there is extremely little interaction between engines, and that interaction is protected for multithreaded processes (if the library is compiled with USE_THREADS).

If you have more than one thread executing scripts on the same engine you will have much larger interaction between the threads with script global variables and even reference counting on the engine and the contexts. It may work, but I cannot guarantee it.

If you can, I definetely recommend that you implement your own scheduler for the script threads, that run each script in short periods and then switch to the other. You may look at the samples 'concurrent' and 'events' in the sdk 2.2.0, for an example on how this works. To the scripts it will give the same apparent result, but to the application it will be much safer since you will not have potential conflicts in resources.

Multithreading is extremely complicated in a scripting library, especially one that uses reference counting as resource management. However I want to make AngelScript safer for multithreaded use so if you find some troublesome areas, let me know and I'll see what I can do to make them safe.

Regards,
Andreas

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Ok,

When I get some tests going I'll see how it performs.

My biggest issue is that I attempt to preallocate and initiate the script engine instances so that when a person desires to execute a script, they do not have to wait for the build process.

I believe actually what I will do instead is skip the registration of script objects until the 1st build of a script and use seperate instantiations of each object.

Share this post


Link to post
Share on other sites
also, I know i've read it before, but is it possible to have a script call a function that registers more objects/methods with the currently executing script engine?

Share this post


Link to post
Share on other sites
It should be possible to register objects and methods while executing a script, however this is not official and I cannot guarantee that it will be possible in the future. At least not the same way as currently.

I'm planning on changing the way the engine is configured, to make it dynamic, i.e. functions/objects can be unregistered again. It will also be more flexible in that parts of the configuration can be made available only to specific script modules, if that is desired.

Share this post


Link to post
Share on other sites
Ok.

The reason I ask is because I am designing a plugin module to allow more specific interaction with whatever program the plugin decides to offer more specific functionality.

My original idea and the one I may decide to go with is to just search a 'Plugins' directory and load any dlls that are in that directory. The dll then registers whatever functions/objects with the script engine (through getprocaddress and a pointer to the script engine of course). The problem is that if there are 20 viable plugins in the directory, the script engine becomes extremely large due to 20 plugins having registered more objects/functions. Moreover, each instance of an executing script engine will 99% of the time only desire use the functions from 1 or maybe 2 modules.

Therefore I wondered whether it was possible to register a script function that in turn resulted in registering more items with the engine instance.

Perhaps I will just allow the user to explicity choose which plugins they desire before a script engine is registered. Also, along these lines, the future addition of unregistering objects will be a handy feature for me.

Share this post


Link to post
Share on other sites
I've been thinking about a plug-in system for my Texture Generator as well.

What I intend to do there is to let the script writer put in preprocessor commands, e.g. #plugin "perlinnoise". When the application loads the script it searches for these preprocessor commands, and configures the script engine accordingly and only after that compiles and executes the script.

Maybe you can do something like that?

Having a script function tell the application to register the plugins would require you to first compile that script function and execute it and then compile the rest of the script. It seems like it would be a bit awkward.

Regards,
Andreas

Share this post


Link to post
Share on other sites
Just an update.

I added the preprocessor directive: #plugin

It is used in this form:

#plugin "mypath\myplugin.dll"


The dll exports only 1 function, that I find and call. The function takes a pointer to an asIScriptEngine and registers any objects/functions/properties that the dll contains.

works like a charm.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!