Yes perhaps, but what would the advantage be ?
More to the point: what is the behavior of 'new' in case of failure to obtain
memory ?
I would assume some kind of assert.
/AndersBj
________________________________
From: hano [mailto:[email protected]]
Sent: den 24 mars 2015 16:05
To: [opensaf:tickets]
Subject: [opensaf:tickets] #1268 IMM: Server side behavior at failure to
allocate memory needs to be consistent
one option is, as imm is implemented in c++ to call
std::set_new_handler(new_handler) in main and use new/delete instead of
malloc/free. Then if calls to new fails the new_handler will be called,
so no error checking has to be done around the new calls, amfd uses this
pattern.
________________________________
[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 17, 2015 09:49 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 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:** Tue Mar 24, 2015 03:05 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 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
