Exception handling for c++ has a reputation of sometimes adding quite some
overhead to *normal* processing.
In any case osafasset and just plain raw segv are acceptable in my world for
the very rare problem of not being able to allocate memory.
At some point we could convert the entire server code to pure c++, but it is
not the highest priority right now.
/AndersBj
________________________________
From: Anders Widell [mailto:[email protected]]
Sent: den 25 mars 2015 09:48
To: [opensaf:tickets]
Subject: [opensaf:tickets] #1268 IMM: Server side behavior at failure to
allocate memory needs to be consistent
We have been talking about introducing an xmalloc() function for a long time,
though with the current naming conventions that I have been using when adding
utility functions it should probably be named osaf_malloc(). The osaf_malloc()
function would be guaranteed to always be successful if it returns. I.e. if it
fails it will not return, but instead log to syslog and call _Exit().
There is a ticket for adding these types of utility functions:
[#777]<http://sourceforge.net/p/opensaf/tickets/777>.
For C++, it is probably better to use new as Hans suggests. We should also make
sure to log uncaught exceptions, that logs to syslog and generates a core dump.
This will catch cases like e.g. index out of bounds exceptions in STL classes.
________________________________
[tickets:#1268]<http://sourceforge.net/p/opensaf/tickets/1268> IMM: Server side
behavior at failure to allocate memory needs to be consistent
Status: unassigned
Milestone: future
Created: Tue Mar 17, 2015 09:49 AM UTC by Anders Bjornerstedt
Last Updated: Tue Mar 24, 2015 03:38 PM UTC
Owner: nobody
The IMM server side (IMMND and IMMD) should behave consistently and follow
a consistent coding pattern for dealing with the case of failure to allocate
memory.
Failure to allocate memory in the server is rare and means that the the
processor
where the server is executing is overloaded. The server is for all practical
purposes doomed. The best behavior for this case is for the server to terminate.
The alternative of continuing but failing to provide the service is more likely
to complicate the situation than help. Escalation becomes clearer, faster and
simpler if the imm server fails fast in this case.
In terms coding, the simplest solution possible should be used. The allowed
solutions in coding on the server side should be:
a) osafassert the pointer after malloc/calloc/strdup....
b) Nothing, i.e. segv at the next dereference.
where (a) is recommended, but (b) allowed.
Writing explict code for checking for null, writing syslog error messages etc
is not allowed in the server. Less code is better in this case. The server side
must not have code for returning ERR_NO_MEMORY to the client.
________________________________
Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/opensaf/tickets/1268/<https://sourceforge.net/p/opensaf/tickets/1268>
To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/<https://sourceforge.net/auth/subscriptions>
---
** [tickets:#1268] IMM: Server side behavior at failure to allocate memory
needs to be consistent**
**Status:** unassigned
**Milestone:** future
**Created:** Tue Mar 17, 2015 09:49 AM UTC by Anders Bjornerstedt
**Last Updated:** Wed Mar 25, 2015 08:48 AM UTC
**Owner:** nobody
The IMM server side (IMMND and IMMD) should behave consistently and follow
a consistent coding pattern for dealing with the case of failure to allocate
memory.
Failure to allocate memory in the server is rare and means that the the
processor
where the server is executing is overloaded. The server is for all practical
purposes doomed. The best behavior for this case is for the server to terminate.
The alternative of continuing but failing to provide the service is more likely
to complicate the situation than help. Escalation becomes clearer, faster and
simpler if the imm server fails fast in this case.
In terms coding, the simplest solution possible should be used. The allowed
solutions in coding on the server side should be:
a) osafassert the pointer after malloc/calloc/strdup....
b) Nothing, i.e. segv at the next dereference.
where (a) is recommended, but (b) allowed.
Writing explict code for checking for null, writing syslog error messages etc
is not allowed in the server. Less code is better in this case. The server side
must not have code for returning ERR_NO_MEMORY to the client.
---
Sent from sourceforge.net because [email protected] is
subscribed to http://sourceforge.net/p/opensaf/tickets/
To unsubscribe from further messages, a project admin can change settings at
http://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a
mailing list, you can unsubscribe from the mailing list.
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Opensaf-tickets mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
