longjmp()
David Warme
David at Warme.net
Thu Mar 6 03:55:32 UTC 2014
I am posting this to gmp-devel (instead of gmp-discuss) because it
concerns very arcane GMP implementation details.
The GMP manual on Custom Allocation contains the following paragraph:
There's currently no defined way for the allocation functions
to recover from an error such as out of memory, they must
terminate program execution. A longjmp or throwing a C++
exception will have undefined results. This may change in
the future.
From the outside, it is not easy to see why longjmp() would have
undefined results -- the C standard does a pretty good job of
defining what its behavior should be, and it is the contract of
any conforming C compiler (e.g., GCC) to assure this behavior.
One thing that comes to mind is that GMP isn't written entirely in
C, but has lower-level pieces written in assembly language. It is
my understanding, however, that these pieces do not generally
engage in memory allocation, freeing, or reallocation, but require
that the given buffers are already of sufficient size for the
operation. As such, none of these assembly routines should be
active anywhere in the call stack when the allocation / reallocation
routines are invoked (unless assembly is interrupted by a signal
whose handler invokes GMP routines -- but that is an entirely
different can of worms!).
Another possibility is that blocks allocated using the TMP_DECL,
TMP_MARK, and TMP_FREE mechanisms (if too large for alloca())
would not (automatically) be freed when calling longjmp().
This would obviously have to be done manually (for the frames
being popped) before longjmp() could be called. If exhaustive
marking were implemented, however, one could always rely upon a
garbage collector to reclaim such blocks since they would be
unreferenced after longjmp() executes.
Yet another could be the need to "pop" some sort of (thread local?)
activation stack of the TMP_MARK entries using
__gmp_tmp_reentrant_free(). GMP 5.1.3 does not seem to implement
any method for creating/maintaining such an activation stack of
TMP_MARK entries, however.
What sort of issues do the GMP developers have in mind when adding
this paragraph to the manual? Are there others I have overlooked?
More information about the gmp-devel
mailing list