[interfacekit] Re: BHandler::fToken

Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx> wrote:
> > aren't being used.  Granted, your box would have to be up a *very* 
> > long
> > time before you overflowed the counter; nevertheless, it would be 
> > nice
> > if the general case was that you either got a token based on the 
> > counter
> > or from the queue rather than having to do the check.
> As I wrote in my previous mail, I believe, a single check (i.e. 
> lookup in
> the hash map) is cheap -- an `add if not already existing', if 
> available,
> would be at no additional cost at all -- and actually I suspect it to 
> be
> even cheaper than removing a token from the queue.
> 
> Anyway, even if you have a million used tokens, the token space is 
> still
> rather empty. In average you had to do one additional check per 4000
> invocations. However, a token is allocated when a BHandler is 
> created.
> That is usually not exactly a time critical operation in itself. So, 
> even
> if the million used tokens form one big cluster -- a million hash 
> table
> lookups won't take more than a fraction of a second on modern 
> machines
> anyway -- that shouldn't do much harm.

I think that's a good point: the overflow of the IDs will be extremely 
rare and I would bet all my time/money/whatever that we will never 
reach it in my lifetime (sure, as long as I am the kernel guy, I could 
just hard-reset the machine when it comes close ;-))
So that's why optimizing it for that case just makes not much sense, 
even less so because looking up an item in the hash is really very 
cheap.
Just have this additional check Ingo suggests would actually be an 
optimization for the first 4 billion cases, where I think we should 
spend our energy on for now :-)

Adios...
   Axel.

Other related posts: