Nope. The suggestion was to provide another way programs can deal with
OOM situations. They can take advantage of it or not.
> And what ever happened to soemone argument about checking/handling NULL
> was more work for the programmer? Hmm? Which is more? Implementing a
> scheme where your prorgam will attempt to free as much memory as posible
> or making sur eyou never use more than you need to begin with.
The scheme is not quite comparable and is not in competition with malloc=NULL,
it's a rather orthogonal issue:
- malloc=NULL is about telling the program `sorry you can't allocate because
there's no more memory for you'
- the map-trick scheme proposed is rather along the lines of `here, I'm a
nice citizen so if memory is getting tight, feel free to use that memory
since I don't absolutely need it'.
Both schemes can live peacefully together. Tho my opinion is still that
malloc should never return NULL (this doesn't mean that the application
should not be told when there's no more memory, but another mechanism would be
preferable).
> But maybe this would be something to implement atop the application layer,
> something behind thescenes and mostly handeld by the kernel.
This would probably be hidden behind some nice interfaces. I admit not
knowing how to make such a thing `nice'.
> Personally, I would like a malloc() that freed my memory when I felt it
> should be freed. I woudl also expect my program to actually have access
> to the memory that it was told it had access to.
The proposal in relation with malloc was to allow reclamation of pages that
currently belong to the malloc library but not to the application (so there's
no impact on the applications).
This all sounds a bit overkill indeed.
Stefan
-
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/