OK, I see now. The implementation using low-level GMP would be more
parallel with Roger's original version, right?
That would end up being simpler than having reserve memory, as well as
stabler.
Since you currently mark blocks that are to be freed by GMP, you could
make this change piecemeal, right? When you rewrite addition to use the
low-level routines, you mark the blocks allocated by addition as J not
GMP, and everything else follows automatically.
Tbat's a great idea.
hhr
On 10/24/2023 8:34 PM, Raul Miller wrote:
libzahl is not thread safe, and even if it was, it's not clear to me
that it adequately supports enough architectures.
Meanwhile, libgmp's problems are addressable. I just have to use a
different part of its API.
(Also, on windows, we're using mpir rather than libgmp.)
(J currently uses parts of the libgmp high level API, which performs
memory allocations within the libgmp library routines, using callbacks
whose implementation I supply. But it also exposes the low level
routines used to build those high level routines, and those low level
routines do not perform memory allocation, which means that we can
manage the memory outside of the API.)
((The problem with libgmp's high level API is that if a memory
allocation fails, it exits the program. So we came up with a
workaround which reserves a memory pool, and limits arguments to
certain routines, so successful memory allocations will succeed even
under low memory conditions. That's not ideal, but it has been "good
enough, so far". But libgmp supports another approach. It's a little
more work, but not an excessive amount of work.))
I hope this makes sense,
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
