You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Dirk-Willem van Gulik <di...@covalent.net> on 2001/10/12 22:56:09 UTC
Granularity of mtime
On some versions of Linux/Solaris fstat(2) gives you a second granularity
of mtime/atime/ctime. On some other OS-es/versions you get mSec's.
Is there a way to ask APR what the granularity is ?
Dw
Re: Granularity of mtime
Posted by Ryan Bloom <rb...@covalent.net>.
On Friday 12 October 2001 07:52 pm, Roy T. Fielding wrote:
> On Fri, Oct 12, 2001 at 05:22:04PM -0700, Dirk-Willem van Gulik wrote:
> > > > > Is there a way to ask APR what the granularity is ?
>
> Is it right to assume that the reason you need this is so that the httpd
> will mark a message with a Date that is later than the Last-Modified, hence
> avoiding problems with HTTP/1.1's caching algorithm?
>
> If so, it is probably more efficient to simply add a second to the Date
> field value string than to try to sleep.
>
> If not, never mind.
>
> I still think that apr_time_t should be in seconds with a separate field
> for microseconds. One of these years I'll find the time for that patch.
That was where we started with apr_time_t's. Dean moved it to the current
model, and he had some good reasons at the time.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: Granularity of mtime
Posted by Dirk-Willem van Gulik <di...@covalent.net>.
On Fri, 12 Oct 2001, Roy T. Fielding wrote:
> On Fri, Oct 12, 2001 at 05:22:04PM -0700, Dirk-Willem van Gulik wrote:
> > > > > Is there a way to ask APR what the granularity is ?
>
> Is it right to assume that the reason you need this is so that the httpd
> will mark a message with a Date that is later than the Last-Modified, hence
> avoiding problems with HTTP/1.1's caching algorithm?
>
> If so, it is probably more efficient to simply add a second to the Date
> field value string than to try to sleep.
:-) The issue at hand is actually interacting with a benchmark test -
where one needs to use stat/fstat/lstat to see if a file has changed
(rather than shared memory, some internal signal, etc) - but cause apache
is quite quick - the next RQ is often within the second window.
Dw
Re: Granularity of mtime
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
On Fri, Oct 12, 2001 at 05:22:04PM -0700, Dirk-Willem van Gulik wrote:
> > > > Is there a way to ask APR what the granularity is ?
Is it right to assume that the reason you need this is so that the httpd
will mark a message with a Date that is later than the Last-Modified, hence
avoiding problems with HTTP/1.1's caching algorithm?
If so, it is probably more efficient to simply add a second to the Date
field value string than to try to sleep.
If not, never mind.
I still think that apr_time_t should be in seconds with a separate field
for microseconds. One of these years I'll find the time for that patch.
....Roy
Re: Granularity of mtime
Posted by Dirk-Willem van Gulik <di...@covalent.net>.
On Fri, 12 Oct 2001, Cliff Woolley wrote:
> > > Is there a way to ask APR what the granularity is ?
> >
> > All APR times are mSec.
>
> Yes, but if the OS stores only seconds for the mtime, the APR time is
> seconds*APR_USEC_PER_SEC, right? So while there are extra zeros at the
> end, that doesn't necessarily mean there's extra precision. So if you
> want to sleep just long enough to ensure that the mtime will be different,
> what do you do? I guess you have to assume worst case... (is that 1s or
> is it more than that?)
>From trying on Solaris and Linux - 2 seconds sleep is the minimum (and
Linux's 2 second sleep seems to be 1.8 second wall clock sometimes).
Dw
Re: Granularity of mtime
Posted by Cliff Woolley <cl...@yahoo.com>.
On Fri, 12 Oct 2001, Ryan Bloom wrote:
> On Friday 12 October 2001 01:56 pm, Dirk-Willem van Gulik wrote:
> > On some versions of Linux/Solaris fstat(2) gives you a second granularity
> > of mtime/atime/ctime. On some other OS-es/versions you get mSec's.
> >
> > Is there a way to ask APR what the granularity is ?
>
> All APR times are mSec.
Yes, but if the OS stores only seconds for the mtime, the APR time is
seconds*APR_USEC_PER_SEC, right? So while there are extra zeros at the
end, that doesn't necessarily mean there's extra precision. So if you
want to sleep just long enough to ensure that the mtime will be different,
what do you do? I guess you have to assume worst case... (is that 1s or
is it more than that?)
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: Granularity of mtime
Posted by Ryan Bloom <rb...@covalent.net>.
On Friday 12 October 2001 01:56 pm, Dirk-Willem van Gulik wrote:
> On some versions of Linux/Solaris fstat(2) gives you a second granularity
> of mtime/atime/ctime. On some other OS-es/versions you get mSec's.
>
> Is there a way to ask APR what the granularity is ?
All APR times are mSec.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: Granularity of mtime
Posted by Dirk-Willem van Gulik <di...@covalent.net>.
On Fri, 12 Oct 2001, Dirk-Willem van Gulik wrote:
> On some versions of Linux/Solaris fstat(2) gives you a second granularity
> of mtime/atime/ctime. On some other OS-es/versions you get mSec's.
>
> Is there a way to ask APR what the granularity is ?
Just to clarify - I want to put a 'sleep()' into my code which is long
enough to guarantee that the mtime() of some file created is different
of the current time when we come out of the routine.
Dw.