On Fri, 4 Jan 2008, Dag-Erling Sm=F8rgrav wrote:

quoted text
> "Igor Mozolevsky" <igor@hybrid-lab.co.uk> writes:
>> This makes memory management in the userland hideously and unnecessarily=
=20
quoted text
>> complicated. It's simpler to have SIGDANGER [...]
>
> You don't seem to understand what Poul-Henning was trying to point out,=
=20
quoted text
> which is that broadcasting SIGDANGER can make a bad situation much, much=
=20
quoted text
> worse by waking up and paging in every single process in the system,=20
> including processes that are blocked and wouldn't otherwise run for sever=
al=20
quoted text
> minutes, hours or even days (getty, inetd, sshd, mountd, even nfsd / nfsi=
od=20
quoted text
> 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=
=20
malloc(3) returning NULL when memory is getting tight, and while we have ne=
ver=20
done exactly that, we have historically had malloc(3) return NULL when we g=
et=20
close to the process data segment size.

Robert N M Watson
Computer Laboratory
University of Cambridge