Date: Tue, 8 Jan 2008 10:19:42 +1100 From: Andrew Reilly <andrew-freebsd@areilly.bpc-users.org> To: "Poul-Henning Kamp" <phk@phk.freebsd.dk> Cc: Kostik Belousov <kostikbel@gmail.com>, Peter Jeremy <peterjeremy@optushome.com.au>, freebsd-current@freebsd.org, Igor Mozolevsky <igor@hybrid-lab.co.uk> Subject: Re: sbrk(2) broken Message-ID: <20080108101942.05471233@duncan.reilly.home> In-Reply-To: <10319.1199711927@critter.freebsd.dk> References: <a2b6592c0801070515g37735475kc0922af8f93723ca@mail.gmail.com> <10319.1199711927@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 07 Jan 2008 13:18:47 +0000 "Poul-Henning Kamp" <phk@phk.freebsd.dk> wrote: > Yes, but you will not see this complication, it will be hidden > in the implementation of malloc(3). How could you hide it inside malloc? Would malloc start returning 0 after receiving the "less mem than desirable" signal? Would it ever go back to returning non-zero? I thought that the idea of things like SIGDANGER was that applications would be written to have a mode where they could shut down some aspect of their operation, and free resources. I don't see how you can do that, autonomously, from within malloc? Maybe introduce a special flavour of pointer value, returned by a special version of malloc for "cache" objects, that the system is allowed to automatically reclaim? Then programs would need to be able to handle SIGSEGV when accessing those... Cheers, -- Andrew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080108101942.05471233>