John Morris writes:
Not a problem at all. An API is a contract, violate it at your peril.
Let's see...
The malloc() call's contract is you request memory with the understanding that "no" is a legal answer.
Indeed. But keep in mind what the contract actually is. NULL means there was an error, but a problem such as lack of RAM doesn't require malloc() to return NULL. The contract does not include isn't a bijective equivalence, only an injective implication. In the words of the linux man page, "when malloc() returns non-NULL there is no guarantee that the memory really is available".
I have personally seen linux/glibc malloc return non-NULL even though there was FAR too little RAM, and also seen it return NULL even though there was more than enough RAM (the hardware was purchased for the software). If you think hard enough about malloc's contract you'll understand how the latter is possible.
If you fail to account for that possibility (tactics like preallocation) you either made a mistake or worse, failed to understand the nature of the deal. On the other hand, a tactic of simply allowing the process that hits the memory limit to die, thus freeing up some memory, might be the winning move. If you can't accept that, program in a language which deals with those sort of low level details for you and accept the solution it chooses when a request for memory fails. C isn't for everyone and isn't the best answer to every problem. After all, wrapping malloc in a simple test for NULL and exit beats just assuming any malloc will succeed.
Let's assume, for the sake of argument, that this really were true. No oom-killer, no overcommit, errors returned locally to first allocation. What difference does if (!(a=malloc(12314)) exit(42) make compared to e.g. the oomkiller?
The grandparent message (by Stephanie Dougherty) argued that unplanned exits tend to have an actionable and problematic root cause. My response argued that those also happen because of routine occurences such as a server running near capacity combined with the simplicity of operator new, malloc() and a few other similarly simple things.
You argue that... what? C isn't for everyone, you write. Do you mean to suiggest that C isn't for writing servers, or C isn't suitable if one wishes to run a rackful of servers near their maximum capacity? Or do you suggest that when a server process quits because of if(!malloc()) exit() that has different implications regarding restarts and reliability than if the process is killed by the oomkiller? Or what?
Arnt _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
