Memory management

Memory management is one of the most complex and important topics in the programming world, to the point that many people say that all a program does is actually handling memory. True or not, our approach to the matter is the usual one: do not impose policies but let the host developer decide what's best.

Given the enormous number of different (and sometimes incompatible) solutions available, for the first release we limit to just offering two facilities:

• the nacore_set_generic_mem_funcs() function allows host developers to indicate which implementation of the malloc(), realloc(), calloc() and free() functions have to be used by this library;
• host libraries are given the possibility to create a nacore_host_t variable which can be associated to a set of generic memory handling functions and use it when calling functions of other NASPRO-core based libraries supporting this feature via an extra parameter;

Repeating this scheme on each layer of the framework makes it possible to associate a set of memory handling functions to a particular layer and let lower layers use them on the data they handle for it.

The memory lock

Similarly to the errno case, memory allocation functions are not always thread-safe. Normally, to use them in a thread-safe way, one would use a lock and remember to lock and unlock it everytime such memory handling functions are used.

Again, the problem arises when using external libraries in the same exact way as before. And again the solution offered by this library is, in practice, the same: along with the set of memory handling functions associated with some host, the application developer can specify the couple of locking/unlocking functions to use and remember to call them when using functions from other libraries using the same memory handling functions.

The only difference here is that the NASPRO core library can only know about the thread-safety of the system malloc(), etc. implementation (hard coded), but not about third-party allocators, for which the application is responsible.

Future directions

For the (not too far) future, it's my opinion that we need a better memory handling approach, capable of being far more fine tuned. It should be possible to mix several memory handling strategies, optionally passing to the library more memory allocators, each with a specific purpose (a general purpose one, another for memory slices/chunks, yet another with real-time performance, etc.)

In order to do this, many of the existing approaches should be studied in depth (together with their APIs) and possible uses should be categorized with extreme care.