You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Cliff Woolley <jw...@virginia.edu> on 2003/06/25 07:29:14 UTC
remaining issues prior to 1.0?
What are the real issues stopping us from releasing APR 1.0? (Yes, I've
read the STATUS file.) We've been "pushing toward" 1.0 for almost a year
now...
--Cliff
RE: remaining issues prior to 1.0?
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 02:24 AM 7/2/2004, William A. Rowe, Jr. wrote:
>[...]
>And in hind site - I don't see any reason we can't implement signals on
>win32 using the existing API. The ctime issue was brought up again
>and seems to be pretty important. And mapping ACL's on HPUX/Win32
>and Linux/SE seems like it's own ballgame that would
... be it's own incremental version bump, e.g. 1.1 or whatnot. No need
to hold up 1.0.
Sorry, full of incomplete thoughts today - it's been a long week.
Bill
RE: remaining issues prior to 1.0?
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
While researching ->ctime thoughts on list... (the entire thread might be
enlightening to review for those who want some weekend reading :)
Nearly a year ago, At 11:09 AM 6/25/2003, William A. Rowe, Jr. wrote:
>At 03:27 AM 6/25/2003, Marc M. Adkins wrote:
>>> * emulating the daemon/services foo within the Win32 port... but call it
>>> a 'nice to have' ... I will try to dedicate cycles to this over
>>> the summer.
>>> It's not exactly a showstopper.
>>
>>Can you expand on this? Are you talking about the usual "Windows doesn't
>>fork" problem, emulating Windows services on Linux, getting process data
>>(memory size, CPU %, etc.) or something else entirely?
>>
>>Just curious.
>
>although I would *really* like to deal with fork() ... it isn't practical (topic
>for another thread).
>
>I was restricting my focus to mapping Service 'Events' -> Unix Signals,
>such as stop, start, shutdown, and marking Apache as 'already daemonized'
>when you start as a service.
>
>My only headache - I spent some time trying to find how we can safely
>assert that this WinNT/2K/XP/2003 process is running within the SCM
>(NT kernel service control manager). The short answer so far; it isn't
>very pretty. If we knew that, we would have APR react and start a service
>control thread, and then enter the NT event processing loop.
>
>On the Win9x side, implement daemonize_process to dismiss the window
>and mark the process as a 'psuedo-service'. Again, the hidden window we
>create to track Apache shutting down would trigger our 'unix' signals.
>
>so it looks on NT as
>
>apr_app_initialize()
>\-> Running as service?
> \-> Spin up service monitor and nt eventlog capture thread for stderr
> \-> In service monitor thread, call into the SCM to be called back.
> \-> Fix the argv[] based on the ServiceStart args.
>
>and then react to service control signals to the monitor thread based on
>our apr_signals() API.
>
>The only other two big thorns left in APR? File Create time isn't the same
>as the inode modified ctime. And we don't have an API to map ACL
>management between implementations, nor a way for Win32 to handle
>setuid(). In Win32's case, we need the account 'password' to deal with
>a setuid() request. The first is a real bug to fix, the second is perhaps
>beyond the scope of releasing 1.0.
And in hind site - I don't see any reason we can't implement signals on
win32 using the existing API. The ctime issue was brought up again
and seems to be pretty important. And mapping ACL's on HPUX/Win32
and Linux/SE seems like it's own ballgame that would
RE: remaining issues prior to 1.0?
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 03:27 AM 6/25/2003, Marc M. Adkins wrote:
>> * emulating the daemon/services foo within the Win32 port... but call it
>> a 'nice to have' ... I will try to dedicate cycles to this over
>> the summer.
>> It's not exactly a showstopper.
>
>Can you expand on this? Are you talking about the usual "Windows doesn't
>fork" problem, emulating Windows services on Linux, getting process data
>(memory size, CPU %, etc.) or something else entirely?
>
>Just curious.
although I would *really* like to deal with fork() ... it isn't practical (topic
for another thread).
I was restricting my focus to mapping Service 'Events' -> Unix Signals,
such as stop, start, shutdown, and marking Apache as 'already daemonized'
when you start as a service.
My only headache - I spent some time trying to find how we can safely
assert that this WinNT/2K/XP/2003 process is running within the SCM
(NT kernel service control manager). The short answer so far; it isn't
very pretty. If we knew that, we would have APR react and start a service
control thread, and then enter the NT event processing loop.
On the Win9x side, implement daemonize_process to dismiss the window
and mark the process as a 'psuedo-service'. Again, the hidden window we
create to track Apache shutting down would trigger our 'unix' signals.
so it looks on NT as
apr_app_initialize()
\-> Running as service?
\-> Spin up service monitor and nt eventlog capture thread for stderr
\-> In service monitor thread, call into the SCM to be called back.
\-> Fix the argv[] based on the ServiceStart args.
and then react to service control signals to the monitor thread based on
our apr_signals() API.
The only other two big thorns left in APR? File Create time isn't the same
as the inode modified ctime. And we don't have an API to map ACL
management between implementations, nor a way for Win32 to handle
setuid(). In Win32's case, we need the account 'password' to deal with
a setuid() request. The first is a real bug to fix, the second is perhaps
beyond the scope of releasing 1.0.
Bill
Out of band data (was issues prior to 1.0?)
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 10:01 AM 6/25/2003, Bill Stoddard wrote:
>William A. Rowe, Jr. wrote:
>>
>>Let me add
>>* no support of out-of-band network data whatsoever. That really concerns
>> me and I will probably address it over the next two weeks.
>
>Elaborate please.
send() takes a fourth argument, such as OOB. Our apr_send() has no such
support for out of band data. On recv, there are a couple of ways of recovering
out of band data, and we should support one or more models.
Once APR can handle it, it's trivial to finish the minimal telnet protocol filter
I'm working on. If we see an out-of-band IP/Sync sequence, I can drop that
into a custom metadata bucket, and conventional (read: fast) server applications
can simply drop them on the floor. The entire OOB construct doesn't really
fit into server apps running on 1GHz CPU, but they still must be acknowledged
in order to implement minimal-telnet, which is a requirement for SMTP, FTP
and a number of other telnet control-channel based protocols.
>* real problems with files opened for sendfile, which no longer block correctly
>> on win32, e.g. our entire logic may be invalid. Try filtering any buckets
>> prepared for sendfile on win32 with the XTHREAD logic to see the issue.
>Sounds like a Windows bug to me but certainly worth investigating more. I would be very against moving away from the use of the SENDTIMEO/RCVTIMEO model on Windows unless it is definitively proven that Windows is broken and that MS has no intent to fix the brokeness.
I agree - no doubt it's a Win32 bug. My observation is that when you take
a 5MB file, destined to be 'sendfile'd (so it's open with XTHREAD - overlapped
I/O model), and mmap it in order to filter it, the apr_sendv() call will return
immediately as if the data is sent. We do nothing therein around overlapped
I/O, in fact the overlapped arg is NULL. So the simple bug appears to be that
any file opened for sendfile cannot be mmaped and WSASend()'t.
After the discovery, I've been too buried in small transfer mechanics to
revisit this huge transfer bug. But I'm guessing this is behind some of
the complaints from PHP and other forums that the "bug in XP afd.sys"
appears to affect more users than those that should be affected.
Bill
Re: remaining issues prior to 1.0?
Posted by Bill Stoddard <bi...@wstoddard.com>.
William A. Rowe, Jr. wrote:
>At 01:04 AM 6/25/2003, Justin Erenkrantz wrote:
>
>
>>--On Wednesday, June 25, 2003 1:29 AM -0400 Cliff Woolley <jw...@virginia.edu> wrote:
>>
>>
>>
>>>What are the real issues stopping us from releasing APR 1.0? (Yes, I've
>>>read the STATUS file.) We've been "pushing toward" 1.0 for almost a year
>>>now...
>>>
>>>
>>Off the top of my head I would suggest:
>>
>>* tmpfile handling
>>* random number generation API
>>
>>
>
>Let me add
>
>* no support of out-of-band network data whatsoever. That really concerns
> me and I will probably address it over the next two weeks.
>
Elaborate please.
>
>* real problems with files opened for sendfile, which no longer block correctly
> on win32, e.g. our entire logic may be invalid. Try filtering any buckets
> prepared for sendfile on win32 with the XTHREAD logic to see the issue.
>
Sounds like a Windows bug to me but certainly worth investigating more.
I would be very against moving away from the use of the
SENDTIMEO/RCVTIMEO model on Windows unless it is definitively proven
that Windows is broken and that MS has no intent to fix the brokeness.
Bill
RE: remaining issues prior to 1.0?
Posted by "Marc M. Adkins" <mm...@Doorways.org>.
> * emulating the daemon/services foo within the Win32 port... but call it
> a 'nice to have' ... I will try to dedicate cycles to this over
> the summer.
> It's not exactly a showstopper.
Can you expand on this? Are you talking about the usual "Windows doesn't
fork" problem, emulating Windows services on Linux, getting process data
(memory size, CPU %, etc.) or something else entirely?
Just curious.
mma
Re: remaining issues prior to 1.0?
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 01:04 AM 6/25/2003, Justin Erenkrantz wrote:
>--On Wednesday, June 25, 2003 1:29 AM -0400 Cliff Woolley <jw...@virginia.edu> wrote:
>
>>What are the real issues stopping us from releasing APR 1.0? (Yes, I've
>>read the STATUS file.) We've been "pushing toward" 1.0 for almost a year
>>now...
>
>Off the top of my head I would suggest:
>
>* tmpfile handling
>* random number generation API
Let me add
* no support of out-of-band network data whatsoever. That really concerns
me and I will probably address it over the next two weeks.
* real problems with files opened for sendfile, which no longer block correctly
on win32, e.g. our entire logic may be invalid. Try filtering any buckets
prepared for sendfile on win32 with the XTHREAD logic to see the issue.
* emulating the daemon/services foo within the Win32 port... but call it
a 'nice to have' ... I will try to dedicate cycles to this over the summer.
It's not exactly a showstopper.
Re: remaining issues prior to 1.0?
Posted by Ben Laurie <be...@algroup.co.uk>.
Justin Erenkrantz wrote:
> * random number generation API
uh-oh!
... but yes, it is approaching the top of my list!
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Re: remaining issues prior to 1.0?
Posted by Bill Stoddard <bi...@wstoddard.com>.
Justin Erenkrantz wrote:
> --On Wednesday, June 25, 2003 1:29 AM -0400 Cliff Woolley
> <jw...@virginia.edu> wrote:
>
>> What are the real issues stopping us from releasing APR 1.0? (Yes, I've
>> read the STATUS file.) We've been "pushing toward" 1.0 for almost a
>> year
>> now...
>
>
> Off the top of my head I would suggest:
>
> * tmpfile handling
> * random number generation API
+1
Bill
Re: remaining issues prior to 1.0?
Posted by Cliff Woolley <jw...@virginia.edu>.
> So, no real reason other than no one has time... -- justin
Tell me about it. Grad school didn't used to be this busy... but they
sure are keeping me on my toes this year! Sheesh! :)
Re: remaining issues prior to 1.0?
Posted by Aaron Bannert <aa...@clove.org>.
On Tuesday, June 24, 2003, at 11:04 PM, Justin Erenkrantz wrote:
> Off the top of my head I would suggest:
>
> * tmpfile handling
> * random number generation API
>
> I could conceivably believe that we could push these to post-1.0 if we
> had consensus to do so.
These sound like new features to me, not broken features. These don't
need to hold up a release.
-aaron
Re: remaining issues prior to 1.0?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Wednesday, June 25, 2003 1:29 AM -0400 Cliff Woolley
<jw...@virginia.edu> wrote:
> What are the real issues stopping us from releasing APR 1.0? (Yes, I've
> read the STATUS file.) We've been "pushing toward" 1.0 for almost a year
> now...
Off the top of my head I would suggest:
* tmpfile handling
* random number generation API
I could conceivably believe that we could push these to post-1.0 if we had
consensus to do so.
So, no real reason other than no one has time... -- justin
Re: remaining issues prior to 1.0?
Posted by "William A. Rowe, Jr." <wr...@apache.org>.
At 07:28 PM 9/1/2003, Justin Erenkrantz wrote:
>> Brian Pane wrote:
>>
>> Here's my attempt at summarizing all the proposals.
>> There was a lot of debate about the naming of the time
>> type--whether it was good or bad to give it a name so
>> similar to time_t, whether the type name should reflect
>> an implementation like binary microseconds, etc. For
>> simplicity, I'll just describe the implementations as
>> I remember them, independent of the naming issues.
>
>My take is that what we have now is fine for 1.0. Perfect? No. So be
>it. It works.
I agree here - I don't like the downsides of any of the alternatives (who does?)
but no longer prefer binary microseconds for the following reason...
...if you take a sample several times for delta time arithmetic you will get
rounding errors. Are these more significant than samples taken and summed
using the obvious rounding errors of 10(-6) decimal math? Probably not, but
users will be puzzled and frustrated by these sorts of discrepancies.
>Any changes to the time code can be in the next major release. This will
>give us enough time to appropriately discuss what should go in there.
1.0 is the major release.
>IIRC, there was also an explicit veto on any change to the time code
>because it could break source and/or binary compatibility. Therefore, if
>that veto still stands, we have to do any changes to the time code *after*
>1.0 not before. And, for lots of other reasons, I tend to agree to do it
>after 1.0.
I believe the veto was over changing this in the .9 development branch...
although this might be a developer's version, it is widely deployed today
and needs to be treated as a 'stable' version.
So for 1.0 itself, anything goes if we can come to concensus.
>Count me as post-1.0 for any time fixes. -- justin
Re: remaining issues prior to 1.0?
Posted by Stas Bekman <st...@stason.org>.
Cliff Woolley wrote:
> On Tue, 2 Sep 2003, Stas Bekman wrote:
>
>
>>3) there is no apr_file_tell
>>http://marc.theaimsgroup.com/?t=100748110600004&r=1&w=2
>
>
> You don't need one. Just as there is an lseek() but no ltell(), you can
> do:
>
> apr_off_t offs = 0;
> apr_file_seek(fd, APR_CUR, &offs);
>
> at which point offs will have been updated to contain the current absolute
> position of the file pointer.
>
> The same thing applies to sysseek() in perl, by the way... there is no
> systell().
Thanks Cliff, wrowe has already suggested that back when I have asked about
it. I just thought that having a function for tell() will be useful, but I'm
fine without it as well.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: remaining issues prior to 1.0?
Posted by Cliff Woolley <jw...@virginia.edu>.
On Tue, 2 Sep 2003, Stas Bekman wrote:
> 3) there is no apr_file_tell
> http://marc.theaimsgroup.com/?t=100748110600004&r=1&w=2
You don't need one. Just as there is an lseek() but no ltell(), you can
do:
apr_off_t offs = 0;
apr_file_seek(fd, APR_CUR, &offs);
at which point offs will have been updated to contain the current absolute
position of the file pointer.
The same thing applies to sysseek() in perl, by the way... there is no
systell().
--Cliff
Re: remaining issues prior to 1.0?
Posted by "William A. Rowe, Jr." <wr...@apache.org>.
At 12:04 AM 9/3/2003, Stas Bekman wrote:
>Justin Erenkrantz wrote:
>>--On Tuesday, September 2, 2003 2:30 PM -0700 Stas Bekman <st...@stason.org> wrote:
>>
>>>Other outstanding issues that IMHO can/should be fixed in 1.0.
>>>
>>>Configure issues:
>>>
>>>1) dealing with APR_HAS_LARGE_FILES on linux
>>>http://marc.theaimsgroup.com/?l=apr-dev&m=105277560530754&w=2
>>>Currently it's just disabled, even when available.
>>>the whole thread is here:
>>>http://marc.theaimsgroup.com/?t=105271796700002&r=1&w=2
>>
>>IMHO, this isn't a 1.0 showstopper. Someone who has a Linux box can step up and add the right configure logic. No API change is required here. We don't need to hold up 1.0 because no Linux developers care to fix it. (I don't have access to Linux boxes with working sendfile64, so I'm of zero help here.)
Might I humbly suggest that we *ignore* the issues with sendfile64 and simply
use largefiles, period? If they want apr_sendfile to behave, someone will step
up and fix it.
AFAICT, there are few 32-bit file size restrictions in the modern world.
Bill
Re: remaining issues prior to 1.0?
Posted by Joe Orton <jo...@manyfish.co.uk>.
On Tue, Sep 02, 2003 at 10:04:52PM -0700, Stas Bekman wrote:
> Justin Erenkrantz wrote:
> >--On Tuesday, September 2, 2003 2:30 PM -0700 Stas Bekman
> ><st...@stason.org> wrote:
> >
> >>Other outstanding issues that IMHO can/should be fixed in 1.0.
> >>
> >>Configure issues:
> >>
> >>1) dealing with APR_HAS_LARGE_FILES on linux
> >>http://marc.theaimsgroup.com/?l=apr-dev&m=105277560530754&w=2
> >>Currently it's just disabled, even when available.
> >>the whole thread is here:
> >>http://marc.theaimsgroup.com/?t=105271796700002&r=1&w=2
> >
> >
> >IMHO, this isn't a 1.0 showstopper. Someone who has a Linux box can
> >step up and add the right configure logic. No API change is required
> >here. We don't need to hold up 1.0 because no Linux developers care to
> >fix it. (I don't have access to Linux boxes with working sendfile64, so
> >I'm of zero help here.)
>
> Isn't here anybody who understands the ./configure logic on linux?
If you just want a 64-bit apr_off_t on your 32-bit Linux you can already
just use
./configure CPPFLAGS="-D_FILE_OFFSET_BITS=64"
but changing the size of apr_off_t (and hence changing the library ABI)
is serious business - that's not a decision I'd want in the hands of a
configure check.
(you can get large file support without changing the size of apr_off_t,
but that's not simply a case of writing some configure gunk)
joe
Re: remaining issues prior to 1.0?
Posted by Stas Bekman <st...@stason.org>.
Justin Erenkrantz wrote:
> --On Tuesday, September 2, 2003 2:30 PM -0700 Stas Bekman
> <st...@stason.org> wrote:
>
>> Other outstanding issues that IMHO can/should be fixed in 1.0.
>>
>> Configure issues:
>>
>> 1) dealing with APR_HAS_LARGE_FILES on linux
>> http://marc.theaimsgroup.com/?l=apr-dev&m=105277560530754&w=2
>> Currently it's just disabled, even when available.
>> the whole thread is here:
>> http://marc.theaimsgroup.com/?t=105271796700002&r=1&w=2
>
>
> IMHO, this isn't a 1.0 showstopper. Someone who has a Linux box can
> step up and add the right configure logic. No API change is required
> here. We don't need to hold up 1.0 because no Linux developers care to
> fix it. (I don't have access to Linux boxes with working sendfile64, so
> I'm of zero help here.)
Isn't here anybody who understands the ./configure logic on linux?
>> 1) apr_strfsize is limited to the availability of LARGEFILES support,
>> whereas it's advertised as a general purpose function and has nothing
>> to do
>> with the filesize. The thread that wasn't finished is here:
>> http://marc.theaimsgroup.com/?t=101232935300002&r=1&w=2
>
>
> I'm not understanding why this is related to LARGEFILES at all? Do you
> mean that you'd want this to work with 64-bit integers regardless of
> apr_off_t's size? Don't see that as 'must-fix' before 1.0.
Yes. I suggested that the API name will be changes to reflect the reality.
>> 2) s/ap_ht_time/apr_date_format_http/g
>> http://marc.theaimsgroup.com/?t=101232878000006&r=1&w=2
>> Bill says it's a good API change (move into apr):
>> http://marc.theaimsgroup.com/?l=apr-dev&m=101232960930699&w=2
>
>
> According to the version rules, functions can be added at any time.
> Again, not a 1.0 showstopper.
Alright, but why not doing this simple change. It doesn't take longer than
running s/// and adjusting the header files.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: remaining issues prior to 1.0?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Tuesday, September 2, 2003 2:30 PM -0700 Stas Bekman <st...@stason.org>
wrote:
> Other outstanding issues that IMHO can/should be fixed in 1.0.
>
> Configure issues:
>
> 1) dealing with APR_HAS_LARGE_FILES on linux
> http://marc.theaimsgroup.com/?l=apr-dev&m=105277560530754&w=2
> Currently it's just disabled, even when available.
> the whole thread is here:
> http://marc.theaimsgroup.com/?t=105271796700002&r=1&w=2
IMHO, this isn't a 1.0 showstopper. Someone who has a Linux box can step up
and add the right configure logic. No API change is required here. We don't
need to hold up 1.0 because no Linux developers care to fix it. (I don't have
access to Linux boxes with working sendfile64, so I'm of zero help here.)
> 1) apr_strfsize is limited to the availability of LARGEFILES support,
> whereas it's advertised as a general purpose function and has nothing to do
> with the filesize. The thread that wasn't finished is here:
> http://marc.theaimsgroup.com/?t=101232935300002&r=1&w=2
I'm not understanding why this is related to LARGEFILES at all? Do you mean
that you'd want this to work with 64-bit integers regardless of apr_off_t's
size? Don't see that as 'must-fix' before 1.0.
> 2) s/ap_ht_time/apr_date_format_http/g
> http://marc.theaimsgroup.com/?t=101232878000006&r=1&w=2
> Bill says it's a good API change (move into apr):
> http://marc.theaimsgroup.com/?l=apr-dev&m=101232960930699&w=2
According to the version rules, functions can be added at any time. Again,
not a 1.0 showstopper.
> 3) there is no apr_file_tell
> http://marc.theaimsgroup.com/?t=100748110600004&r=1&w=2
Cliff and I just talked about how you'd solve this in #apr. He's writing a
reply now. -- justin
Re: remaining issues prior to 1.0?
Posted by Stas Bekman <st...@stason.org>.
Other outstanding issues that IMHO can/should be fixed in 1.0.
Configure issues:
1) dealing with APR_HAS_LARGE_FILES on linux
http://marc.theaimsgroup.com/?l=apr-dev&m=105277560530754&w=2
Currently it's just disabled, even when available.
the whole thread is here:
http://marc.theaimsgroup.com/?t=105271796700002&r=1&w=2
API issues:
1) apr_strfsize is limited to the availability of LARGEFILES support, whereas
it's advertised as a general purpose function and has nothing to do with the
filesize. The thread that wasn't finished is here:
http://marc.theaimsgroup.com/?t=101232935300002&r=1&w=2
The solution is simple: rename apr_strfsize to something that implies that it
works with file sizes only and provide a new general purpose function that
works with any size, unrelated to LARGEFILES.
2) s/ap_ht_time/apr_date_format_http/g
http://marc.theaimsgroup.com/?t=101232878000006&r=1&w=2
Bill says it's a good API change (move into apr):
http://marc.theaimsgroup.com/?l=apr-dev&m=101232960930699&w=2
3) there is no apr_file_tell
http://marc.theaimsgroup.com/?t=100748110600004&r=1&w=2
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: remaining issues prior to 1.0?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
> Brian Pane wrote:
>
> Here's my attempt at summarizing all the proposals.
> There was a lot of debate about the naming of the time
> type--whether it was good or bad to give it a name so
> similar to time_t, whether the type name should reflect
> an implementation like binary microseconds, etc. For
> simplicity, I'll just describe the implementations as
> I remember them, independent of the naming issues.
My take is that what we have now is fine for 1.0. Perfect? No. So be
it. It works.
Any changes to the time code can be in the next major release. This will
give us enough time to appropriately discuss what should go in there.
IIRC, there was also an explicit veto on any change to the time code
because it could break source and/or binary compatibility. Therefore, if
that veto still stands, we have to do any changes to the time code *after*
1.0 not before. And, for lots of other reasons, I tend to agree to do it
after 1.0.
Count me as post-1.0 for any time fixes. -- justin
Re: remaining issues prior to 1.0?
Posted by Brian Pane <br...@cnet.com>.
On Thu, 2003-07-03 at 07:31, gregames@apache.org wrote:
> Brian Pane wrote:
>
> >> What are the real issues stopping us from releasing APR 1.0?
>
> > We still have the 64-bit divisions in the apr_time_t code.
>
> It sure would be nice to make this one go away since it is most likely an API
> change. But what are the chances we can come to a consensus on how to do it in
> a reasonable time? Does someone have an objective summary of the proposals we
> could look at, hopefully without starting a flame war?
Here's my attempt at summarizing all the proposals.
There was a lot of debate about the naming of the time
type--whether it was good or bad to give it a name so
similar to time_t, whether the type name should reflect
an implementation like binary microseconds, etc. For
simplicity, I'll just describe the implementations as
I remember them, independent of the naming issues.
1. Current design
How it works:
Time is stored in a 64-bit int as
(time_t * 1,000,000) + microseconds
Pros:
Time arithmetic is fast
Cons:
Extracting the seconds is slow
2. Binary microseconds
How it works:
Time is stored in a 64-bit int as
(time_t << 22) + microseconds
Pros:
Extracting the seconds is fast
Cons:
Extracting the microseconds is slow
3. Stop storing microseconds
How it works:
Time is stored as time_t, with no microseconds
Pros:
Works great for apps that only need seconds
No 64-bit multiplication/division performance
problems
Cons:
Doesn't work so well for apps that do need
microseconds
4. Struct
How it works:
Time is stored as a struct with separate fields
for seconds and microseconds
Pros:
Extracting seconds is fast
Cons:
Time arithmetic is slow
The pros and cons are tricky; the performance tradeoffs
that are ideal for one app may be unbearable for another.
The last time this topic came up, I ended up being in
favor of a variant of option 3:
http://marc.theaimsgroup.com/?m=102678180413988
Brian
Re: remaining issues prior to 1.0?
Posted by gr...@apache.org.
Brian Pane wrote:
>> What are the real issues stopping us from releasing APR 1.0?
> We still have the 64-bit divisions in the apr_time_t code.
It sure would be nice to make this one go away since it is most likely an API
change. But what are the chances we can come to a consensus on how to do it in
a reasonable time? Does someone have an objective summary of the proposals we
could look at, hopefully without starting a flame war?
Greg
Re: remaining issues prior to 1.0?
Posted by Brian Pane <br...@apache.org>.
Cliff Woolley wrote:
>What are the real issues stopping us from releasing APR 1.0? (Yes, I've
>read the STATUS file.) We've been "pushing toward" 1.0 for almost a year
>now...
>
We still have the 64-bit divisions in the apr_time_t code.
Brian