Re: sbrk(2) broken

On Fri, 4 Jan 2008, Dag-Erling Smørgrav wrote:

> "Igor Mozolevsky" <igor_at_hybrid-lab.co.uk> writes:
>> This makes memory management in the userland hideously and unnecessarily 
>> complicated. It's simpler to have SIGDANGER [...]
>
> You don't seem to understand what Poul-Henning was trying to point out, 
> which is that broadcasting SIGDANGER can make a bad situation much, much 
> worse by waking up and paging in every single process in the system, 
> including processes that are blocked and wouldn't otherwise run for several 
> minutes, hours or even days (getty, inetd, sshd, mountd, even nfsd / nfsiod 
> in some cases can sleep for days at a time waiting for I/O)

Another aspect of the problem is that applications have come to depend in 
malloc(3) returning NULL when memory is getting tight, and while we have never 
done exactly that, we have historically had malloc(3) return NULL when we get 
close to the process data segment size.

Robert N M Watson
Computer Laboratory
University of Cambridge