🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
AS currently supports Multithreading or not?
Author
I was looking though the SDK and saw something that said not to execute two scripts at once, then I saw this:
Multithreading
* Multithreading support is off by default, to add the support define the flag USE_THREADS
* The flag NO_THREADS no longer have any effect
I am not sure what that control implys nor where you can set this USE_THREADS.
Anyway I am looking into AS for my scripting language it seem the easy es to embed with c++ compared to everything else I have looked at. I also like the c/c++ style syntax, that is a big plus. I have 3 questions that are keeping me from making my decision.
1) Like I said before, to what extent can I use multithreading?
2) On it's own does the language support any OO features? Can I create a class like object in the script and derive new objects from it. Say I have a base class for vehicles in my c++ code and I expose that to the script, if I create a base vehicle in the script can I make new vehicle from it else where in my script?
3) Can I compile the script in to binarys to reduce load times and to protect people form getting into the script files if I were ever to ship something with it.
Thanks for any help!
1) If you need only single threaded access to the script then you don't need to do anything else. With this I mean that only one thread at a time accesses the script engine. There is nothing stopping your application from having threads that does other things.
If you need to have multiple threads accessing the script engine at the same time, then you should compile the library with the preprocessor flag USE_THREADS defined, so that the code for managing threads inside the library is used.
Still, even with the USE_THREADS flag, you'll have to manually implement the necessary features to protect shared resources, like global variables etc. The only thing the library guarantees is that all function calls will work as described, e.g. asGetActiveContext() will return the active context in the current thread, which makes it possible to have two (or more script contexts) running at the same time in different threads.
2) No, it is currently not possible to declare classes in the scripts. I'm starting implementing the feature to declare simple structs in the scripts, but at the beginning they will not be able to derive from application registered classes. It will probably never be possible to derive from normal C++ classes, but if I can find a solution for how to do that I will.
3) Yes, you can store compiled scripts into binary files for later reloading.
If you need to have multiple threads accessing the script engine at the same time, then you should compile the library with the preprocessor flag USE_THREADS defined, so that the code for managing threads inside the library is used.
Still, even with the USE_THREADS flag, you'll have to manually implement the necessary features to protect shared resources, like global variables etc. The only thing the library guarantees is that all function calls will work as described, e.g. asGetActiveContext() will return the active context in the current thread, which makes it possible to have two (or more script contexts) running at the same time in different threads.
2) No, it is currently not possible to declare classes in the scripts. I'm starting implementing the feature to declare simple structs in the scripts, but at the beginning they will not be able to derive from application registered classes. It will probably never be possible to derive from normal C++ classes, but if I can find a solution for how to do that I will.
3) Yes, you can store compiled scripts into binary files for later reloading.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
