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].
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] 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 [email protected] is
subscribed to https://sourceforge.net/p/opensaf/tickets/
To unsubscribe from further messages, a project admin can change settings at
https://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
