32-Bit timeout values

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

> From: rbb@covalent.net [mailto:rbb@covalent.net]
> Sent: Saturday, November 18, 2000 10:05 AM
> 
> On Sat, 18 Nov 2000, William A. Rowe, Jr. wrote:
> 
> > > From: rbb@covalent.net [mailto:rbb@covalent.net]
> > > Sent: Saturday, November 18, 2000 9:47 AM
> > > 
> > > Would it work to just convert the timeout in the server_rec to the
> > > apr_interval_time_t?
> > 
> > We likely need the macro for conversion from apr_time_t to 
> apr_interval_time_t, 
> > as well.  My personal preference, after all was said and 
> done, was not to use
> > interval_time or delta_time, but use short_time, since 
> intervals and deltas
> > are often longer than 35 minutes (except for timeouts, 
> obviously.)  But the
> > interval_time for password caching might certainly be set 
> at an hour.
> 
> Or, and this is just an option, we could use 32-bit interval 
> times.  The
> definition of an interval time is one that starts now and 
> goes into the
> future as opposed to an absolute time value.  I know that as the cache
> work is completed we are going to want hours or possibly days as the
> timeout values.  Let's just simplfy things immensly and call interval
> times 32-bit.  Yes, this does waste 16-bits for timeout's, but that isn't
> the end of the world.

This was argued before.  If you are restarting it, I'm +1 for 32 bit times, 
timeouts, and any other measurement of time, but there are other opinions
out there.

Re: 32-Bit timeout values

[rb...@covalent.net]

> > Or, and this is just an option, we could use 32-bit interval 
> > times.  The
> > definition of an interval time is one that starts now and 
> > goes into the
> > future as opposed to an absolute time value.  I know that as the cache
> > work is completed we are going to want hours or possibly days as the
> > timeout values.  Let's just simplfy things immensly and call interval
> > times 32-bit.  Yes, this does waste 16-bits for timeout's, but that isn't
> > the end of the world.
> 
> This was argued before.  If you are restarting it, I'm +1 for 32 bit times, 
> timeouts, and any other measurement of time, but there are other opinions
> out there.

I'm restarting it, because the current solution is flawed.  So, if there
are other opinions, let's hear them again.

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------