Date: Fri, 4 Jan 2008 13:24:28 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des@des.no> Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, freebsd-current@freebsd.org, Jason Evans <jasone@freebsd.org>, Igor Mozolevsky <igor@hybrid-lab.co.uk> Subject: Re: sbrk(2) broken Message-ID: <20080104132310.X77222@fledge.watson.org> In-Reply-To: <86abnlag4t.fsf@ds4.des.no> References: <86myrlahee.fsf@ds4.des.no> <5647.1199451237@critter.freebsd.dk> <a2b6592c0801040503j650046f5k73895b5b0c84025d@mail.gmail.com> <86abnlag4t.fsf@ds4.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 4 Jan 2008, Dag-Erling Smørgrav wrote: > "Igor Mozolevsky" <igor@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080104132310.X77222>