On Sat, Mar 18, 2000 at 11:07:52PM +0000, Nicholas Vinen wrote:
> Another libc issue. The way I see this working, you get SIGNMEM (or
> whatever) then one of your options is to free some memory. However, when
> you free() or delete [], pages are still allocated. A CLib call, similar
> to "int flushheap()" will need to be implemented, which finds all pages in
> the heap which are totally unallocated and uses some kind of syscall to
> turn them back into COW pages (then returning the count, so you can tell
> if you really managed to free any memory).
glibc2 already does this to a certain extent.
[...]
> SIGNMEM should also set some kind of global variable (similar to errno)
> like "memdeficit" which is how many more pages would need to be freed to
> continue, letting you decide by flushheap()'s return value whether your
> program can continue or not. Also, during SIGNMEM on SMP systems, all
> other processors must sleep. Otherwise the memory situation may not be
> stable across its execution.
Purely userspace semantics and seems overly complex to me.
-cw
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Mar 23 2000 - 21:00:26 EST