Dynamic Programming

The previous sections described how to use dynamic objects (dynamic and shared libraries) that are loaded by the runtime linker at actor start-up. In addition to this mechanism, an actor can also bind a dynamic or shared library explicitly during its execution. This on-demand object binding has several advantages:

• By processing a dynamic object when it is required rather than during the initialization of an application, start-up time can be greatly reduced. In fact, the object might not be required if its services are not needed during a particular run of the application.

• The application can choose between several different dynamic objects depending on the exact services required. For example, if different libraries implement the same driver interface, the application can choose one driver implementation and load it dynamically.

• Any dynamic object added to the actor address space during execution can be freed after use, thus reducing the overall memory consumption.

Typically, an application performs the following sequence to access an additional dynamic object, using the dynamic library API:

• A dynamic object is located and added to the address space of a running application using dlopen(). Any dependencies this dynamic object has are located and added at this time.

• The added dynamic object and its dependencies are relocated, and any initialization sections within these objects are called.

• The application locates symbols within the added objects using dlsym(). The application can then reference the data or call the functions defined by these new symbols.

• After the application has finished with the objects, the address space can be freed using dlclose(). Any termination section within the objects being freed will be called at this time.

• Any error conditions that occur as a result of using these runtime linker interface routines can be displayed using dlerror().