Method for reusing script engines.
Author
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?
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
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
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.
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.
Author
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?
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.
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.
Author
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.
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.
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
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
Author
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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement