|
List Info
Thread: policy change for correct handling of fatal program conditions
|
|
| policy change for correct handling of
fatal program conditions |
|
2007-01-22 16:10:25 |
Hello,
The bug report "add checks for calloc calls"
(http://bugs.d
igium.com/view.php?id=8295) results in a opportunity to
think again about the used approaches for error handling.
Your current
policy seems to be wrong.
Fatal program conditions like the one that arose from a
failed memory
allocation should not be ignored. How do you think about a
correction
for this issue?
If you are concerned about the service quality for call
management by
your server implementation, I suggest to use alternative
means to
achieve the desired goals and to reduce unplanned
downtimes.
http:/
/en.wikipedia.org/wiki/High_availability
Regards,
Markus
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
|
|
| Re: policy change for correct handling
of fatal program conditions |
|
2007-01-22 19:17:36 |
|
| On Monday 22 January 2007 16:10, SF Markus Elfring wrote:
> The bug report "add checks for calloc calls"
> (http://bugs.digium.com/view.php?id=8295) results in a opportunity to
> think again about the used approaches for error handling. Your
> current policy seems to be wrong.
> Fatal program conditions like the one that arose from a failed memory
> allocation should not be ignored. How do you think about a correction
> for this issue?
We're not suggesting that you ignore the condition, only that you do not
completely abort the Asterisk process. You may abort the current call,
which should free memory for other calls. You may also log the
exceptional condition, for the benefit of the administrator.
A failure of memory allocation for a single call should not affect
processing for any of the other calls in progress on the system.
--
Tilghman
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
|
| Re: policy change for correct handling
of fatal program conditions |
|
2007-01-23 02:12:34 |
|
On Tuesday 23 January 2007 00:10, SF Markus Elfring wrote:
> Hello,
>
> The bug report "add checks for calloc calls"
> (http://bugs.digium.com/view.php?id=8295) results in a opportunity to
> think again about the used approaches for error handling. Your current
> policy seems to be wrong.
Hi all
Has anyone considered the fact that malloc() never actually fails i.e.
memory starvation does not cause malloc() to return error. It always returns
true - when you actually access the memory one will get a SIGBUS (I think)
and the program will die.
This behaviour (called overcommit) is to make the UNIX fork/exec model
efficient. For this reason one should use calloc() because at least then the
failure will occur close to the allocation call in the code.
You can turn this behaviour off by using sysctl but only systemwide which
may make your whole system inefficient.
There have been many discussions about this quirk of malloc. The man page
even describes it as a bug ...
Paul
--
Paul Hewlett Technical Director
Global Call Center Solutions Ltd, 2nd Floor, Milnerton Mall
Cnr Loxton & Koeberg Roads, 7435 Milnerton
paul gccs.co.za www.gccs.co.za
Tel: +27 86 111 3433 Fax: +27 86 111 3520 Cel: +27 76 072 7906
Gizmo: 1 747 659 6171
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
|
[1-3]
|
|
|
about | contact Other archives ( Real Estate discussion Medical topics )
|