Mikhail Teterin wrote:
>
> All I want is that a program gets NULL from malloc if there is no memory
> available. I find that to be a very fundamental thing about malloc.
>
> In response, me and others are told at different times:
>
> . there is no such thing as "no memory available" (!!!)
> . you can get that behaviour by limiting the user's maximum
> datasize
> . this wouldn't work without dumping the overcommit strategy,
> which would demand more memory and will slow things down
> . be a better sysadmin
> . get more memory and swap
> . this discussion is annoying and fruitless (!!!)
>
> I find this responses unacceptable, or only partially acceptable...
There is two ways you can alloc memory: on-demand or pre-allocated.
Most Unixes out there choose on-demand because it let you do more
with less. A *lot* more. The only way to do what you want is to
pre-allocate.
Alas, suppose you set pre-allocation for your eat-all-memory
application. You application starts, eat all memory and stabilizes.
Then you move the mouse in X Free causing previously allocated
memory to be accessed. There is no memory available, so the largest
process is killed. That would be your eat-all-memory application.
What some of us have been telling you is that there is no easy way
out of this. Some have suggested "don't kill this process"
solutions. This is a poor solution, because it requires much more
sysadmin tweaking than limiting user's maximum datasize.
If you pre-allocate all memory you'll find out you have much less
memory available for you. MUCH less.
Yeah, a pre-allocate all memory general system flag would be
interesting, but mostly because we could then say "turn this on and
see how you suddenly don't have memory to even start X Free". Or, in
other words, if you set a maximum datasize for your application, you
can allocate MUCH more memory to that application than if our
allocation strategy was pre-allocate.
Do you have a solution? We don't.
--
Daniel C. Sobral (8-DCS)
d...@newsguy.com
d...@freebsd.org
"nothing better than the ability to perform cunning linguistics"
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
