Resources | developer.brewmp.com Resources | developer.brewmp.com

Developer

resources

Allocating memory in the system context

When a static extension's interface is meant to have a single instance and be shared among applications, or if it exposes an underlying single resource, for example, decoded information in a buffer, the class instance memory should be allocated in the system context. If the extension is allocated in a system context, some care needs to be taken to ensure a destructor is called to clean up the resources. This can be done by linking multiple system objects to the application and creating the instance of the extension to clean up its references and/or to force a cleanup on AEE_Exit(). You can register for a system callback when AEE_Exit() is completing to force the release of the object and re-initialize any pointers or global object data.

If an extension exposes a service, so that each calling application will require its own data to be present, it is usually best for memory to be allocated in the context of the calling application’s module and be allocated once per the MyExtension_New() call. If possible, it is favorable in these situations to have the application allocate the memory and pass the buffer to be filled to the service. If a size determination is needed for the application, exposing an allocation measuring method is advisable. This can be done in a separate API or with certain overloaded parameters to the API that fill the memory. To guard against a resource leak, it is best to tie these instances to the executing application by using AEE_LinkSysObject() to ensure that the destructor is called when the module owning the applet is released.