shrinking memory consumptions
ajackson at redhat.com
Mon Apr 2 17:22:00 EDT 2007
On Tue, 2007-04-03 at 08:34 +1200, Martin Langhoff wrote:
> Yep, it is hard to do because you have to handle it immediately. If
> it's a file you can defer it until you get out of that memory-eating
> loops that's keeping you busy right now... and OOM'ing the box. :-)
> If that's the case, doing it via signals is the right thing to do, and
> it _is_ hard. Moving it to a pollable mechanism makes it easier, and
> of very limited use -- ie: only when your app is idle.
> Or perhaps I am completely misunderstanding.
I can get a signal on any file descriptor I want already, because I have
SIGIO. fd's generalise to signals .
You usually can't release anything meaningful within a signal handler
anyway because you have no guarantee that it's safe to call free(). And
if you _are_ calling free() in a signal handler, I'm sure
full-disclosure@ will be hearing about your app someday.
If you're single-threaded and interactive (like a typical X app, or the
X server for that matter), then you need to be doing your work in
digestible increments anyway for latency reasons, so you may as well do
the pressure-release at the top of your main loop. I'd argue that this
is by far the most common class of app we'll see on OLPC, since it's the
dominant class on actual desktops right now.
 - yes, technically you can do the pipe-to-self trick to turn your
signals into an fd, but that's gross and you know it. Also ISTR there
being race conditions in doing that, but I'm not recalling the details.
More information about the Devel