On Thu, Jan 7, 2016 at 3:45 PM, Niels Möller <[email protected]> wrote: > Yichao Yu <[email protected]> writes: > >> We (julia) catches the SIGFPE generated by GMP and raise our own >> error. > > Out of curiosity, what are you doing on error? Display a message and > exit the process, or do you try to continue? At the very least, you > could suffer memory leaks, and perhaps leave other gmp objects in an > inconsistent state.
We essentially `longjmp` to the frame that is setup to catch the error. > > Maybe it would be simple and helpful to add a global error callback > pointer (where you could install a function looking up some thread-local > storage, if you want something thread-specific). But robust cleanup from That would work too. (And I guess the default one can throw a FPE so it should be backward compatible). The handler actually doesn't need to be thread local but the issue is `raise(SIGFPE)` can raise the exception on another thread..... > errors is quite tricky (it has been discussed on list from time to > time, one possibility is to combine it with custom memory allocators > with markers, and let the error handler longjmp out and clean up and > deallocate transient storage). > > That said, it sounds reasonable to me to replace abort by raise(SIGFPE). > A configure check may be needed; I think both abort and raise are ANSI > C, but I suspect SIGFPE isn't. Hmm. What about `#ifdef` on `SIGFPE` and `abort` otherwise. This should be a sane enough default for the even when the custom handler is added. > > Depending on pthreads functions is undesirable. > > Regards, > /Niels > > -- > Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. > Internet email is subject to wholesale government surveillance. _______________________________________________ gmp-devel mailing list [email protected] https://gmplib.org/mailman/listinfo/gmp-devel
