abort on error - is this being addressed?

[Joerg Arndt]

* Niels Möller <nisse at lysator.liu.se> [Aug 26. 2010 14:41]:
> Joerg Arndt <arndt at jjj.de> writes:
> 
> > Specifically, OOM for GMP just means "cannot proceed".  What could
> > be "acceptable behaviour" has been cunningly left open in the above
> > comment.
> 
> For an interactive number theory system like PARI/GP: Abort the current
> computation, display an error message, and return to the GP prompt.

Note at this point the operations in the current call tree
are all lost.  I agree the behavior of PARI/GP is the
best possible modulo a huge effort for improvement.

That's why I
  alias gp='gp -q -s 600M'


> For
> an ssh server using GMP for keyexhange operations: Disconnect the one
> client that requested the operation, and maybe write a message to syslog.

Applications like this should make a genuine effort to avoid
potentially catastrophic failure.  Still: is it even granted
the error message makes it to the terminal (as opposed to:
the print-call triggers just another OOM)?

Also one process running into OOM may trigger some (O/S's)
OOM-killer, potentially murdering other processes.
(I have seen this, the OOM-killer snuffed X11... bad!)


> 
> That said, with common unix-like systems with virtual memory,

Without virtual memory things would be _much_ worse,
in very many ways.


> overall
> system behaviour at out of memory is typically awful, no matter how
> libraries and applications handle failure from malloc.

Running out of resources (mem, disk, global thinhs like
shared mem segments) is exceedingly hard to handle
beyond just printing an error message and exiting.

I'd be surprised if things where any better on any O/S
(modulo possibly IBM's z-monsters).


I see two scenarios for GMP usage:

With "scientific" (high performance) computing knowing
the resource requirements beforehand is usually a must.

Where OOM must absolutely be avoided (crypto-apps) I'd
suggest to pre-allocate an upper bound of required memory
as a pool.


The most one can hope for in a library like GMP is that
allocations are (reasonably) easy to spot so they can
be modified as needed for the intended purpose.
And yes, documented upper bounds on mem usage of certain
operations would make MPFR folk's life easier
(no idea whether this has already been addressed/resolved).

> 
> Regards,
> /Niels
> 
> -- 
> Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
> Internet email is subject to wholesale government surveillance.

cheers,   jj