From: jak@rudolph.ccur.com (Joe Korty)
Message-Id: <200212101514.PAA15602@rudolph.ccur.com>
Subject: Re: [PATCH 3/3] High-res-timers part 3 (posix to hrposix) take 20
To: george@mvista.com (george anzinger)
Date: Tue, 10 Dec 2002 10:14:35 -0500 (EST)
Cc: akpm@digeo.com (Andrew Morton), torvalds@transmeta.com (Linus Torvalds),
       linux-kernel@vger.kernel.org (linux-kernel@vger.kernel.org)
Reply-To: joe.korty@ccur.com (Joe Korty)
In-Reply-To: <3DF5A62C.242E171@mvista.com> from "george anzinger" at Dec 10, 2002 12:30:36 AM
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1085
Lines: 24

[ repost - first attempt failed to get out ]

> > Is the "don't reuse an ID for some time" requirement still there?
>
> I don't see the need for the "don't reuse an ID for some
> time" thing and it looked like what Jim had messed up the
> book keeping AND it also looked like it failed to actually
> work.  All of this convinced me that the added complexity
> was just not worth it.

A thought: any algorithm that fails to "reuse an ID for some time"
can be converted into one that does by tweaking the algorithn to
return an ID with fewer bits and putting a counter (bumped on each
fresh allocation of that ID) in the remaining bits.  Or, one can go
stateless and achieve an "almost never reuse an ID for some time" by
instead inserting a freshly generated pseudo-random number in the
unused ID bits.

Joe - Concurrent Computer Corporation
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/