[asterisk-dev] policy change for correct handling of fatal program conditions

[Tilghman Lesher]

On Tuesday 23 January 2007 05:27, SF Markus Elfring wrote:
> > You may abort the current call, which should free memory for other calls.
>
> Are you sure that enough space will become available for further processing
> of a retry?

No, but other threads should observe the same principle.  If they are unable
to allocate sufficient space to continue the call, then they should abort
their own call only, possibly logging that information.  At no point should
any call thread abort processing for another call thread.  It's probable that,
at some point, enough memory will be freed to continue the processing of
some existing calls.

Another possible course of action might be for a thread, upon reaching the
out-of-memory condition, to initiate a "restart when convenient", which, while
not affecting calls in progress, would start the process down the road towards
clearing a memory leak.  This action may need more consideration by the core
developers before it would get committed, but it should be indicative that
we're open to the idea of "solving" the production problem of a memory leak
affecting call processing (just not by aborting all calls in progress).

> > A failure of memory allocation for a single call should not affect
> > processing for any of the other calls in progress on the system.
>
> It would be nice if that can be really achieved.

That's why this is a policy commitment.

-- 
Tilghman