lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev Options, V.Links, random (was: patch 6 - UI Pages)


From: Klaus Weide
Subject: Re: lynx-dev Options, V.Links, random (was: patch 6 - UI Pages)
Date: Wed, 15 Dec 1999 19:59:33 -0600 (CST)

> > Btw., the filename space for the 'straight counter' implementation is 
> > *much* 
> > bigger than the current 'pseudo-random pick out of 10000' implementation. 
> > You have UINT_MAX possible different names before wraparound occurs. 
> 
On Wed, 15 Dec 1999, T.E.Dickey wrote:
> yes (but 10000 files is also probably larger than anyone would use during one
> session, I thought).

For randomly picked numbers (supposedly independently and equally
distributed), the total number of files created in one session isn't
really that important.

Consider instead the number of temp files existing (and kept track of
by lynx) at any one point in time.  Let's say there are 20 - that's a
realistic value, what with source_cache, a few UI pages, a few downloads.

What are the chances that, among 20 filenames drawn out of 10000 (with
repetition allowed), at least 2 are the same?  I get: approximately
190/10000.  (Can anyone confirm, or is my math just way off? :) )

So, at any point in time, there's a 1.9 per cent chance that two files
collide!  Definitely not a negligible effect.  Unless, as I said, my
math is wrong.



> > >   + is the code that opens temp-filenames working properly when it finds 
> > >     a collision. 
> >  
> > I think the last one is the critical one.  If the answer is YES, the rest 
> > hardly matters. 
> 
> well I'll check & see if I think it's working properly.  (It would be not
> very good to allow Lynx to overwrite a file made by the current session,
> for example ;-)

No problem with that, if filenames repeat only after one UINT_MAX
cycle.  A file made by the current session just won't be reached again
by cycling, in any realistic time.  There is a problem only with the
random number filenames.

  Klaus


reply via email to

[Prev in Thread] Current Thread [Next in Thread]