I'm having some trouble with asIScriptModule objects being destroyed while I'm still using them. I've been using module->GetEngine()->AddRef() and module->GetEngine()->Release() to use the ref counts on the engine, but with revisions 350 and 351 that doesn't seem to be adequate. Is there some way to keep asIScriptModule objects alive that I'm missing?

The modules can get destroyed in two ways:

1. The application calls engine->GetModule(mod, asGM_ALWAYS_CREATE);
2. The application calls engine->DiscardModule(mod);

The first option internally calls DiscardModule before creating the new one with the same name.

DiscardModule doesn't immediately destroy the module if there are still objects alive that were implemented by that module.

Is there some way to reset a module without discarding it then? Right now my issue is that from .NET with garbage collection I don't have deterministic destruction of objects so I can't guarantee everything with a module pointer is destroyed before I call DisardModule().

Calling ResetGlobalVars() will reinitialize the global variables, without recompiling the module.

Calling Build() on the original module would reset it as a new script is compiled.

You may also rename the module with SetName(), so that you can create a new one with the original name.



This will improve with future versions, as I'm changing the internal structure of the engine. The modules will no longer be the owner of the memory, but will rather serve as an interface to the scope. This will allow easier reuse of the module without interfering with objects that are still alive. It will also allow the application to dynamically add/remove functions and variables from a module without having to recompile the entire script.

Would renaming a module with the name of an existing module destroy the old module?

Actually, no. The only result of that is that the functions that use the module name to identify the module will use the one that is found first (giving a rather random behaviour).

I'm moving away from using the name of the module to identify modules in the engine methods, so this will be less of a concern in future versions. But for now you'll most likely try to avoid reusing the name of existing modules (unless you don't plan on accessing the modules anymore).

Actually, no. The only result of that is that the functions that use the module name to identify the module will use the one that is found first (giving a rather random behaviour).

I'm moving away from using the name of the module to identify modules in the engine methods, so this will be less of a concern in future versions. But for now you'll most likely try to avoid reusing the name of existing modules (unless you don't plan on accessing the modules anymore).