[OPEN-ILS-DEV] PATCH: transport_message.[ch] (miscellaneous)

[Scott McKellar]

--- Mike Rylander <mrylander at gmail.com> wrote:

[snip]

> I'd consider going even further and say "if we run out of memory, all
> bets are off."  This code is not meant to, nor built to, recover from
> "oh crap I ran out of memory on my multi-gig production server," and,
> in fact, we recycle processes often enough that it would take a
> catastrophic bug or maliciously crafted message (which are both
> bigger
> problems than running out of memory) to cause this in practice.

When I introduced the code for caching allocated-but-unused 
jsonObjects, I included a function to free all of the jsonObjects on
the free list.  One purpose in doing so was to provide a way to 
scavenge enough memory in an emergency to be able to continue, or 
at least shut down gracefully (which might require some additional
allocations for error messages or whatever).

The way this would work is that any module that maintained a cache
of unused memory, such as jsonObjects, would register a scavenger
function.  When something in utils.c ran out of memory, it would
call all of the registered scavenger functions and try again.  If
the second attempt failed, it would abort, or maybe even do a 
longjump to a previously registered bail-out routine.

I have built this sort of thing before, but so far as I know, the
scavenger functions never needed to be called in practice, so maybe
it was all a waste of time.

I agree that running out of memory will be fairly catastrophic, no
matter what the cause, no matter what we do.  A graceful abort is
probably about as much as we could hope for.  Under Linux we probably
can't even do that much, because so far as I know, we can't detect
the memory exhaustion except by crashing.

Scott McKellar