Re: PATCH - raise max_anon limit

[Jim Houston <jim.houston@ccur.com>]

On Wed, 2004-02-11 at 20:20, Andrew Morton wrote:
> Tim Hockin <thockin@sun.com> wrote:
> > No, it doesn't store the counter with the id.  They expect you to do that.
> > My best understanding is that thi sis to prevent re-use of the same key.
> > I'm not sure I grok why it is useful.  If you release a key, it should be
> > safe to reuse.  Period.  I assume there was some use case that brought about
> > this "feature" but if so, I don't know what it is.  The big comment about it
> > is just confusing me.
> 
> Maybe Jim can tell us why it's there.  Certainly, the idr interface would
> be more useful if it just returned id's which start from zero.

Hi Andrew, Everyone,

If this new use of idr.c as a sparse bitmap catches on, it might deserve
a new flavor which would not waste the space for the pointer array
at the lowest layer.

When I wrote the original code, I was thinking of allocating process
id values where there is a tradition of allocating sequential values.
 
George Anzinger rewrote most of my code.  The r in idr.c is for
immediate reuse.  His version picks the lowest available bit in the
sparse bitmap.  The RESERVED_BITS comments seem to be stale.

The rational for avoiding immediate reuse of id values is to catch
application errors.   Consider:

	fd1 = open_like_call(...);
	read(fd1,...);
	close(fd1);
	fd2 = open_like_call(...);
	write(fd1...);

If fd2 has a different value than the recently closed fd1, the
error is detected immediately.

Jim Houston - Concurrent Computer Corp.