I have some script objects which call asGetActiveContext in their constructors, using information from the custom user data. Since the asCModule::ResetGlobalVars function now takes a context pointer, those objects function properly.

I also need to have access to the context in the destruction of those objects, but there is no "active" context when a module is being discarded or when a context is being unprepared. Could the asCModule::Discard function be changed to take a context, and could the asCContext::Unprepare function be changed to set itself to the active context before releasing objects?

I haven't provided a patch myself, because I'm not sure if those changes would clash with the design or if there is some subtle issue with setting a context to the active one as it is unprepared.

Thanks

There is no use in providing a context to the asCModule::Discard or asCContext::Unprepare to do what you want, since there may still be objects that are not destroyed directly by these calls. If the objects are garbage collected they will only be destroyed when the garbage collector is certain that they are dead, which may not be immediately upon Discard or Unprepare.

However, with the release of 2.29.0 I implemented support for exactly what you need with the addition of SetContextCallbacks to the engine interface. Through these callbacks the application has the means to provide user data and initial settings even for script contexts used internally by the engine (for example to call the destructor during garbage collection).

Not only will these callbacks be used when the engine internally needs a context, but the add-ons also request their contexts through the same callback by calling RequestContext on the engine and then return it with ReturnContext. Thus, by using these callbacks you can easily provide a single source of contexts with correct configuration for all executions.

Regards,

Andreas