Previous: Exceptions, Up: MPFR Basics [Index]
MPFR functions may create caches, e.g., when computing constants such
as Pi, either because the user has called a function like
mpfr_const_pi
directly or because such a function was called
internally by the MPFR library itself to compute some other function.
At any time, the user can free the various caches with
mpfr_free_cache
. It is strongly advised to do that before
terminating a thread, or before exiting when using tools like
‘valgrind’ (to avoid memory leaks being reported).
MPFR internal data such as flags, the exponent range, the default precision and rounding mode, and caches (i.e., data that are not accessed via parameters) are either global (if MPFR has not been compiled as thread safe) or per-thread (thread local storage, TLS). The initial values of TLS data after a thread is created entirely depend on the compiler and thread implementation (MPFR simply does a conventional variable initialization, the variables being declared with an implementation-defined TLS specifier).
By default, MPFR uses the GMP memory allocators
(see Section “Custom Allocation” in GNU MP)
instead of malloc
for all its allocations. But since caches have
been introduced in MPFR and nothing had been documented about necessary
clean-up if the GMP allocators had to be changed (by the application or
another library), the current GMP allocators are memorized the first
time they are used by MPFR, and MPFR will always use these allocators.
This means that the allocators need to remain valid as long as MPFR is
used. To avoid this requirement, future versions may handle memory
allocation differently, and applications that change the allocators
may have to be slightly modified.
Previous: Exceptions, Up: MPFR Basics [Index]