Next: , Previous: , Up: Use Considerations   [Index]

15.4 Sharing Library Objects Sets

Library objects may be memory expensive, the libaime ones certainly are. Applications that concurrently run several aime programs may like to reuse the set of library objects. And there should be no problem with that, if the concerns that affect the library objects construction are shared between the executed programs.

The latter include the set of data types, the error reporter and the memory allocators. The last are not likely to be shared between programs, as the applications would presumably like to keep the memory spaces of the executed programs separated. Even if that is the case, the libraries set may still be reused.

One simple path to library reuse is describing the application concerns (such as memory allocation) as proxies. The constructs would not perform the tasks expected of them on their own, but would look up the correspondent program specific construct and would defer the job to it. The proxies would pick up the program specifics from a recorded address, where it is updated by the application as it switches between executed programs.

A similar switch is described for the error reporting redirection of the error trapping library.

See Error Redirection Mechanics.

Of the several memory allocators recognized by the libaime executive objects, the library data memory allocator poses the least challenges, as it allocates data for the executive objects proper, and that does not change. The data memory allocator will not function right if the memory spaces of the executed program are to be kept separated, unless a proxy or a technique of similar effect is used. The temporaries allocator is trickier yet, as its interface and operation are more elaborated.

Next: , Previous: , Up: Use Considerations   [Index]