Matthew Dillon once wrote:
> If you unset the datasize limit and the program does not exceed
> the maximum system-supported datasize limit, malloc() should not
> return NULL even if the system is out of swap.
Can you explain why? Our malloc(3) is a little fuzzy as to the
circumstances under which malloc will fail, but on Solaris, it is
more explicit:
RETURN VALUES
If there is no available memory, malloc(), realloc(),
memalign(), valloc(), and calloc() return a null pointer.
I consider being out-of-swap as having "no available memory". Wouldn't you?
Now, for better diagnostics and for a possibility of smarter applications,
they also have:
ERRORS
If malloc(), calloc(), or realloc() returns unsuccessfully,
errno will be set to indicate the following:
ENOMEM size bytes of memory exceeds the physical
limits of your system, and cannot be allo-
cated.
EAGAIN There is not enough memory available AT THIS
POINT IN TIME to allocate size bytes of
memory; but the application could try again
later.
> The correct solution is to set a maximum datasize limit. That is
> what it is there for. I generally unlimit the datasize for root
> and set it to around 64MB for all other users.
Wait, I want to give all the memory available to a program, but I
want it to be NOTIFIED when no more memory is left. True, I can
set the limit to the actual amount of my swap, but that would be
hard to maintain and still does not solve a problem of running
together with some other memory consuming application.
The existing situation is sort of like killing a program for trying
to write to disk in excess of the user's quota, or for being ready
to RUN when the load is 1.
-mi
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
