[STATUS] (apr-serf) Wed Jul 10 23:45:30 EDT 2002
APR-SERF STATUS:-*-text-*- Last modified at [$Date: 2002/07/01 15:51:57 $] Release: RELEASE SHOWSTOPPERS: We need code. This project's goal is to create an http client library. * web pages (go to apr-site) * decide on layout of the repository (e.g. subdirs) Greg thinks: prolly the following: /build, /include, /docs, /test, /core, and some for high-level items (maybe /filters and /utils) Justin says: Fine with me except /core can't be used as autoconf trounces this directory via rm -rf - how about /base? * set up config/build structure based on apr-util (take this opportunity to simplify again; hopefully to fold these simplifications back into apr(-util)) * release scripts (in /build) (and a how-to-release.txt in docs/) RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP:
Re: [PATCH] fixes for apr_vformatter
Looks like PR9932 explains why we have the current behavior... Not sure if the change from (sp = bep) - (sp bep) makes sense in this case. We most likely need to flush when we are *at* bep, but I'm not really sure. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
RE: cvs commit: apr/include/arch/win32 fileio.h networkio.h
Well, you beat me by about five minutes. I just finished compiling
almost the exact same code.
Thanks for doing to work, your implementation is cleaner than mine was.
:-)
Ryan
--
Ryan Bloom [EMAIL PROTECTED]
645 Howard St. [EMAIL PROTECTED]
San Francisco, CA
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 10, 2002 11:22 PM
To: [EMAIL PROTECTED]
Subject: cvs commit: apr/include/arch/win32 fileio.h networkio.h
wrowe 2002/07/10 23:22:22
Modified:.apr.dsp libapr.dsp
poll/unix poll.c
include/arch/win32 fileio.h networkio.h
Log:
Get Win32 building again. Doesn't build clean, but at least it
builds.
poll on win32 may or may not work correctly, but then again, I
don't
believe that httpd needs it at this moment. Not blasting win32's
poll
until coders are done with it.
Revision ChangesPath
1.105 +1 -1 apr/apr.dsp
Index: apr.dsp
===
RCS file: /home/cvs/apr/apr.dsp,v
retrieving revision 1.104
retrieving revision 1.105
diff -u -r1.104 -r1.105
--- apr.dsp 8 Jun 2002 22:19:50 - 1.104
+++ apr.dsp 11 Jul 2002 06:22:22 - 1.105
@@ -266,7 +266,7 @@
# End Source File
# Begin Source File
-SOURCE=.\network_io\win32\poll.c
+SOURCE=.\network_io\unix\poll.c
# End Source File
# Begin Source File
1.66 +1 -1 apr/libapr.dsp
Index: libapr.dsp
===
RCS file: /home/cvs/apr/libapr.dsp,v
retrieving revision 1.65
retrieving revision 1.66
diff -u -r1.65 -r1.66
--- libapr.dsp 8 Jun 2002 22:19:50 - 1.65
+++ libapr.dsp 11 Jul 2002 06:22:22 - 1.66
@@ -272,7 +272,7 @@
# End Source File
# Begin Source File
-SOURCE=.\network_io\win32\poll.c
+SOURCE=.\network_io\unix\poll.c
# End Source File
# Begin Source File
1.2 +10 -10apr/poll/unix/poll.c
Index: poll.c
===
RCS file: /home/cvs/apr/poll/unix/poll.c,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- poll.c 11 Jul 2002 05:19:45 - 1.1
+++ poll.c 11 Jul 2002 06:22:22 - 1.2
@@ -63,7 +63,7 @@
#include sys/poll.h
#endif
-apr_status_t apr_poll_setup(apr_pollfd_t **new, apr_int32_t num,
apr_pool_t *cont)
+APR_DECLARE(apr_status_t) apr_poll_setup(apr_pollfd_t **new,
apr_int32_t num, apr_pool_t *cont)
{
(*new) = (apr_pollfd_t *)apr_pcalloc(cont, sizeof(apr_pollfd_t)
*
(num + 1));
if ((*new) == NULL) {
@@ -74,7 +74,7 @@
return APR_SUCCESS;
}
-apr_pollfd_t *find_poll_sock(apr_pollfd_t *aprset, apr_socket_t
*sock)
+APR_DECLARE(apr_pollfd_t*) find_poll_sock(apr_pollfd_t *aprset,
apr_socket_t *sock)
{
apr_pollfd_t *curr = aprset;
@@ -88,7 +88,7 @@
return curr;
}
-apr_status_t apr_poll_socket_add(apr_pollfd_t *aprset,
+APR_DECLARE(apr_status_t) apr_poll_socket_add(apr_pollfd_t *aprset,
apr_socket_t *sock, apr_int16_t event)
{
apr_pollfd_t *curr = aprset;
@@ -106,7 +106,7 @@
return APR_SUCCESS;
}
-apr_status_t apr_poll_revents_get(apr_int16_t *event, apr_socket_t
*sock, apr_pollfd_t *aprset)
+APR_DECLARE(apr_status_t) apr_poll_revents_get(apr_int16_t *event,
apr_socket_t *sock, apr_pollfd_t *aprset)
{
apr_pollfd_t *curr = find_poll_sock(aprset, sock);
if (curr == NULL) {
@@ -117,7 +117,7 @@
return APR_SUCCESS;
}
-apr_status_t apr_poll_socket_mask(apr_pollfd_t *aprset,
+APR_DECLARE(apr_status_t) apr_poll_socket_mask(apr_pollfd_t
*aprset,
apr_socket_t *sock, apr_int16_t
events)
{
apr_pollfd_t *curr = find_poll_sock(aprset, sock);
@@ -132,7 +132,7 @@
return APR_SUCCESS;
}
-apr_status_t apr_poll_socket_remove(apr_pollfd_t *aprset,
apr_socket_t
*sock)
+APR_DECLARE(apr_status_t) apr_poll_socket_remove(apr_pollfd_t
*aprset,
apr_socket_t *sock)
{
apr_pollfd_t *curr = find_poll_sock(aprset, sock);
if (curr == NULL) {
@@ -144,7 +144,7 @@
return APR_SUCCESS;
}
-apr_status_t apr_poll_socket_clear(apr_pollfd_t *aprset,
apr_int16_t
events)
+APR_DECLARE(apr_status_t) apr_poll_socket_clear(apr_pollfd_t
*aprset,
apr_int16_t events)
{
apr_pollfd_t *curr = aprset;
@@ -198,7 +198,7 @@
return rv;
}
-apr_status_t apr_poll(apr_pollfd_t *aprset, apr_int32_t num,
+APR_DECLARE(apr_status_t) apr_poll(apr_pollfd_t *aprset,
apr_int32_t
num,
apr_int32_t *nsds,
RE: cvs commit: apr apr.dsp libapr.dsp
I really don't see why we moved the file Just to be clear, I moved the file because poll'ing is no longer tied to sockets. The previous implementation had a serious limitation, in that it couldn't poll pipes or files on platforms that supported it. Because of that limitation, I had put the original file in the network_io directory. That was a mistake years ago, so I took this opportunity to fix it. :-) Ryan
RE: cvs commit: apr/include/arch/win32 fileio.h networkio.h
At 01:25 AM 7/11/2002, Ryan Bloom wrote: Well, you beat me by about five minutes. I just finished compiling almost the exact same code. Thanks for doing to work, your implementation is cleaner than mine was. Speaking of which, are these the results you were looking for? APR Poll Test * Initializing...OK Creating context...OK Creating the sockets I'll use..OK Setting up the pollset I'll useOK Starting Tests Socket 0Socket 1Socket 2 No wait No wait No wait Sending message to socket 2OK Socket 0Socket 1Socket 2 No wait No wait POLLIN! Trying to get message from socket 2OK Sending message to socket 1OK Socket 0Socket 1Socket 2 No wait POLLIN! No wait Sending message to socket 2OK Socket 0Socket 1Socket 2 No wait POLLIN! POLLIN! Trying to get message from socket 1OK Sending message to socket 0OK Socket 0Socket 1Socket 2 POLLIN! No wait POLLIN! Tests completed. Closing socketsOK
apr_poll() done.
Thanks to Will doing the work for Windows, the apr_poll() move is done. Most of the current platforms are actually using a select() based implementation, so instead of duplicating logic again, every platform except for OS/2 is using the Unix poll.c file. The only implementation that is likely to work currently is the Unix implementation. The test suite does have a testpoll.c, which can tell you if the implementation is working, although it is hard to determine if the tests were successful. The important lines are the ones that give the socket status. There should be five of these lines, and they should look like: Socket 0Socket 1Socket 2 No wait No wait No wait No wait No wait POLLIN! No wait POLLIN! No wait No wait POLLIN! POLLIN! POLLIN! No wait POLLIN! The other test that you should run is testpipe. Remember that apr_file_read and apr_file_write use apr_wait_for_io_or_timeout, and that now uses apr_poll(). This means that if the apr_poll() implementation doesn't work on your platform, CGI scripts and any other pipe-based request will fail. Ryan -- Ryan Bloom [EMAIL PROTECTED] 645 Howard St. [EMAIL PROTECTED] San Francisco, CA
RE: cvs commit: apr/include/arch/win32 fileio.h networkio.h
Yep, and I just sent mail letting you know that. :-D Now, you have to run testpipe to make sure that the pipe read is still working. Ryan -- Ryan Bloom [EMAIL PROTECTED] 645 Howard St. [EMAIL PROTECTED] San Francisco, CA -Original Message- From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 10, 2002 11:27 PM To: dev@apr.apache.org Subject: RE: cvs commit: apr/include/arch/win32 fileio.h networkio.h At 01:25 AM 7/11/2002, Ryan Bloom wrote: Well, you beat me by about five minutes. I just finished compiling almost the exact same code. Thanks for doing to work, your implementation is cleaner than mine was. Speaking of which, are these the results you were looking for? APR Poll Test * Initializing...OK Creating context...OK Creating the sockets I'll use..OK Setting up the pollset I'll useOK Starting Tests Socket 0Socket 1Socket 2 No wait No wait No wait Sending message to socket 2OK Socket 0Socket 1Socket 2 No wait No wait POLLIN! Trying to get message from socket 2OK Sending message to socket 1OK Socket 0Socket 1Socket 2 No wait POLLIN! No wait Sending message to socket 2OK Socket 0Socket 1Socket 2 No wait POLLIN! POLLIN! Trying to get message from socket 1OK Sending message to socket 0OK Socket 0Socket 1Socket 2 POLLIN! No wait POLLIN! Tests completed. Closing socketsOK
Re: [PATCH] fixes for apr_vformatter and apr_snprintf
Jim Jagielski wrote:
Nuutti Kotivuori wrote:
Jim Jagielski wrote:
So if truncated, what is returned *must* be = the length passed
in.
apr_snprintf is not snprintf.
Agreed, but we want some of the same characteristics. Returning
length upon truncation is one of them.
* In no event does apr_snprintf return a negative number. It's not
possible to distinguish between an output which was truncated, and
an output which exactly filled the buffer.
If this comment is changed, I can fix try to fix these functions to
behave as expected again.
Seems to me that this is the way apr_snprintf() has evolved to be. I
can't recall the exact reasons why this happened, but I'm sure that
the cvs logs provide the detail. Certainly, ap_snprintf() (from
which apr_snprintf was derived) did not start this way, but was
instead added in to provide an ANSI snprintf() implementation. But
it has since been changed to not be a drop-in replacement of
snprint() with, as you say, documented differences (ala cpystrn())
Jim Jagielski wrote:
I'm guessing that if we *do* need to determine the diff between
truncation and just fits we'd need to change the below
if (sp = bep) {
if (flush_func(vbuff))
return -1;
}
return cc;
to
if (sp bep) {
if (flush_func(vbuff))
return -1;
}
return cc;
since we have a *sp++ to deal with in INS_CHAR (as we want to be
defensive in the coding). But again, the deal is whether that
behavior is a documented feature or bug.
Jim Jagielski wrote:
Looks like PR9932 explains why we have the current behavior... Not
sure if the change from (sp = bep) - (sp bep) makes sense in
this case. We most likely need to flush when we are *at* bep, but
I'm not really sure.
OK, I went around the CVS and I went to see the bug report.
And... I would consider the bugfix a bit of a hack. The problem being
solved there was that when outputting an empty string might cause
apr_psprintf to not handle pools correctly. And sure enough, when
peeking around the code for that, it is _nowhere_ making sure it can
_fit_ it's nul-byte in the pool - it's just blindly assuming the flush
handler to allocate any needed space. In fact:
ps.vbuff.curpos = ps.node-first_avail;
ps.vbuff.endpos = ps.node-endp - 1;
If first_avail == endp, then vbuff.endpos is actually smaller than
curpos. And it's only defensive programming that hides this problem
(using = instead of ==).
IMO, the correct fix would be to make apr_psprintf behave like it
should - make sure there's room for it's nul-byte, instead of
depending on vformatter calling the flush.
***
But back to the subject at hand.
I'm a bit uncertain _how_ am I supposed to be using apr_snprintf so
code doesn't break the next time it's behaviour changes? I'm a bit on
a foul mood here, sorry, but this was supposed to be just a minor
checkup to see if the return value included the nul-byte or not.
So, if I want the length, without including the nul-byte - I need to
compare the return value against the buffer length I passed in, and
substract one if they are equal? I'd like to _depend_ on something
working this way, if I do it this way.
Thanks for your time.
-- Naked
Re: cvs commit: apr/poll/os2 Makefile.in poll.c
On 11 Jul 2002 05:40:23 -, [EMAIL PROTECTED] wrote: rbb 2002/07/10 22:40:23 Modified:network_io/os2 Makefile.in Added: poll/os2 Makefile.in poll.c Removed: network_io/os2 poll.c Log: An attempt at the OS/2 implementation. I have no OS/2 box, so this probably won't work, Yup, not even close :) but at least it is a start. Sure, gets the required file structure in place. My only question is can you select on a file descriptor on OS/2? If not, then we will just have to return an error on OS/2 if somebody tries to. No, OS/2 select only does sockets. I've just written something that appears to work. I only had to rewrite apr_poll() itself, the rest of the functions are the same as for unix. Would it be possible to split unix/poll.c into .c files (apr_poll() in one, helpers in another) so I can share the helper functions? -- __ | Brian Havard | He is not the messiah! | | [EMAIL PROTECTED] | He's a very naughty boy! - Life of Brian | --
Re: [PATCH] fixes for apr_vformatter and apr_snprintf
At 10:17 AM +0300 7/11/02, Nuutti Kotivuori wrote: But back to the subject at hand. I'm a bit uncertain _how_ am I supposed to be using apr_snprintf so code doesn't break the next time it's behaviour changes? I'm a bit on a foul mood here, sorry, but this was supposed to be just a minor checkup to see if the return value included the nul-byte or not. So, if I want the length, without including the nul-byte - I need to compare the return value against the buffer length I passed in, and substract one if they are equal? I'd like to _depend_ on something working this way, if I do it this way. Hmmm... In the current code, if they are equal then it means either it fully fit the buffer or was truncated. So yes. Recall that ap(r)_snprintf() copies at most size-1, so the length of the returned string can only be a maximum of size-1. I agree it looks like we're compromising vformatter for a bug in apr_psprintf... -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
RE: cvs commit: apr/poll/os2 Makefile.in poll.c
From: Brian Havard [mailto:[EMAIL PROTECTED] On 11 Jul 2002 05:40:23 -, [EMAIL PROTECTED] wrote: rbb 2002/07/10 22:40:23 Modified:network_io/os2 Makefile.in Added: poll/os2 Makefile.in poll.c Removed: network_io/os2 poll.c Log: An attempt at the OS/2 implementation. I have no OS/2 box, so this probably won't work, Yup, not even close :) Sorry, but at least I tried. My only question is can you select on a file descriptor on OS/2? If not, then we will just have to return an error on OS/2 if somebody tries to. No, OS/2 select only does sockets. I've just written something that appears to work. I only had to rewrite apr_poll() itself, the rest of the functions are the same as for unix. Would it be possible to split unix/poll.c into .c files (apr_poll() in one, helpers in another) so I can share the helper functions? Of course we can split them out. I had a feeling we would have to. I'll do the work later today. Ryan
RE: [PATCH 2] example binary BUSEC patch for benchmarking only
I ran a quick profile with this patch and it eliminated a couple of divisions (calls to __divi64 reduced from 4 to 2 in my test setup. your mileage may vary) which was good for 493 instructions. Still have 3 __divu64 and 2 __divi64 calls. The three __divu64 calls are in the gettimeofday() CRT function, so there is not much we can do about these directly. One __divi64 is in apr_poll (convert microseconds to milliseconds. This can probably be optimized away). The other __divi64 is somewhere in cached_explode (util_time.c). Bill At 10:38 PM 7/10/2002, William A. Rowe, Jr. wrote: At 10:03 PM 7/10/2002, Brian Pane wrote: Bill Stoddard wrote: I've not looked at the generated code, but profiling indicates that an additional division is happening, adding an extra 231 instructions. (xlc_r -O2) If you redefine the macro as a shift, does the profile look better? Ok, attached is the code redone as binary math. I'm tired, could be any number of major blunders in it, but on first pass, it looked right. Bill
RE: [PATCH 2] example binary BUSEC patch for benchmarking only
From: Bill Stoddard [mailto:[EMAIL PROTECTED] I ran a quick profile with this patch and it eliminated a couple of divisions (calls to __divi64 reduced from 4 to 2 in my test setup. your mileage may vary) which was good for 493 instructions. Still have 3 __divu64 and 2 __divi64 calls. The three __divu64 calls are in the gettimeofday() CRT function, so there is not much we can do about these directly. One Has anybody looked at ExtendedStatus to make sure that we are eliminating all of the time calls that we can during request processing? __divi64 is in apr_poll (convert microseconds to milliseconds. This can probably be If we move to using the macros, it should go away. Ryan
Re: [PATCH 2] example binary BUSEC patch for benchmarking only
At 01:33 AM 07/11/2002, William A. Rowe, Jr. wrote: Ok, attached is the code redone as binary math. I'm tired, could be any number of major blunders in it, but on first pass, it looked right. -/** number of microseconds per second */ -#define APR_USEC_PER_SEC APR_TIME_C(100) +/** number of binary microseconds per second (2^20) */ +#define APR_USEC_PER_SEC APR_TIME_C(1048576) +#define APR_USEC_BITS 20 I keep thinking that APR_USEC_PER_SEC should be (1 20), or now (1 APR_USEC_BITS) instead of the magical constant. I have no way of verifying with a quick glance that 1048576 is really 2^20. -- Greg Marr [EMAIL PROTECTED] We thought you were dead. I was, but I'm better now. - Sheridan, The Summoning
Re: [PATCH 2] example binary BUSEC patch for benchmarking only
Greg Marr wrote: At 01:33 AM 07/11/2002, William A. Rowe, Jr. wrote: Ok, attached is the code redone as binary math. I'm tired, could be any number of major blunders in it, but on first pass, it looked right. -/** number of microseconds per second */ -#define APR_USEC_PER_SEC APR_TIME_C(100) +/** number of binary microseconds per second (2^20) */ +#define APR_USEC_PER_SEC APR_TIME_C(1048576) +#define APR_USEC_BITS 20 I keep thinking that APR_USEC_PER_SEC should be (1 20), or now (1 APR_USEC_BITS) instead of the magical constant. I have no way of verifying with a quick glance that 1048576 is really 2^20. It is :) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: cvs commit: apr/test sendfile.c server.c testfile.c testpoll.c
[EMAIL PROTECTED] writes:
rbb 2002/07/10 22:19:45
Modified:.CHANGES configure.in
file_io/unix readwrite.c
include apr_network_io.h
include/arch/unix networkio.h
network_io/unix Makefile.in sendrecv.c
test sendfile.c server.c testfile.c testpoll.c
Added: include apr_poll.h apr_support.h
poll/unix Makefile.in poll.c
support/unix Makefile.in waitio.c
Removed: network_io/unix poll.c
Log:
Reimplement apr_poll() on Unix. This improves performance by giving the
user back control over the memory in the pollset.
Index: poll.c
===
...
#else/* Use select to mimic poll */
apr_status_t apr_poll(apr_pollfd_t *aprset, int num, apr_int32_t *nsds,
apr_interval_time_t timeout)
{
...
if (aprset[i].events APR_POLLIN) {
FD_SET(fd, readset);
}
if (aprset[i].events APR_POLLOUT) {
FD_SET(fd, writeset);
}
if (aprset[i].events
(APR_POLLPRI | APR_POLLERR | APR_POLLHUP | APR_POLLNVAL)) {
FD_SET(fd, exceptset);
This doesn't look right. The only exception condition (ignoring ttys)
is when there is oob data on the socket.
POLLPRI is okay like this, since oob is considered priority band.
It looks to me that POLLERR should map to readability.
I suspect that POLLHUP should map to readability, but some
experimentation may be necessary.
POLLNVAL is for validating a descriptor and is output only. I don't
see why we even define APR_POLLNVAL.
}
...
aprset[i].revents = 0;
if (FD_ISSET(fd, readset)) {
aprset[i].revents |= APR_POLLIN;
readability from select() means too many different things :)
}
if (FD_ISSET(fd, writeset)) {
aprset[i].revents |= APR_POLLOUT;
}
if (FD_ISSET(fd, exceptset)) {
aprset[i].events |= APR_POLLERR;
no, this is POLLPRI
--
Jeff Trawick | [EMAIL PROTECTED]
Born in Roswell... married an alien...
Re: [PATCH 2] example binary BUSEC patch for benchmarking only
At 10:27 AM 07/11/2002, Jim Jagielski wrote: Greg Marr wrote: I keep thinking that APR_USEC_PER_SEC should be (1 20), or now (1 APR_USEC_BITS) instead of the magical constant. I have no way of verifying with a quick glance that 1048576 is really 2^20. It is :) Well, yes, I did check it, but it's not immediately obvious. :) -- Greg Marr [EMAIL PROTECTED] We thought you were dead. I was, but I'm better now. - Sheridan, The Summoning
Re: cvs commit: apr/support/unix waitio.c
On 11 Jul 2002 [EMAIL PROTECTED] wrote: trawick 2002/07/11 07:39:04 Modified:include apr_poll.h poll/unix poll.c support/unix waitio.c Log: get the new poll code to build on AIX, which for 32-bit builds has some extremely unfortunate macros in sys/poll.h that play with events and revents via #define Can I just say how completely and utterly BOGUS that is. Somebody should really talk to the AIX C run-time team and let them know that it is completely insane that they have that code in their public header files. Ryan -- Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: [PATCH] fixes for apr_vformatter and apr_snprintf
Jim Jagielski wrote: At 10:17 AM +0300 7/11/02, Nuutti Kotivuori wrote: But back to the subject at hand. I'm a bit uncertain _how_ am I supposed to be using apr_snprintf so code doesn't break the next time it's behaviour changes? I'm a bit on a foul mood here, sorry, but this was supposed to be just a minor checkup to see if the return value included the nul-byte or not. So, if I want the length, without including the nul-byte - I need to compare the return value against the buffer length I passed in, and substract one if they are equal? I'd like to _depend_ on something working this way, if I do it this way. Hmmm... In the current code, if they are equal then it means either it fully fit the buffer or was truncated. So yes. Recall that ap(r)_snprintf() copies at most size-1, so the length of the returned string can only be a maximum of size-1. I agree it looks like we're compromising vformatter for a bug in apr_psprintf... OK, so if I make a fix to apr_psprintf to fix it, we can remove the kludge in vformatter? After that apr_snprintf returns len-1 if the data just fit and len if it got truncated. Is this what is wanted? If so, then the canonical code for getting the amount of chars written would be: #define SNPRINTF_MAXLEN int chars = apr_snprintf(buffer, SNPRINTF_MAXLEN, format, ...); if(chars = SNPRINTF_MAXLEN) chars = SNPRINTF_MAXLEN-1; I'll try and code the fix for this once I get a confirmation on this. -- Naked
RE: [PATCH 2] example binary BUSEC patch for benchmarking only
On Thu, 2002-07-11 at 06:58, Bill Stoddard wrote: I ran a quick profile with this patch and it eliminated a couple of divisions (calls to __divi64 reduced from 4 to 2 in my test setup. your mileage may vary) which was good for 493 instructions. Still have 3 __divu64 and 2 __divi64 calls. The three __divu64 calls are in the gettimeofday() CRT function, so there is not much we can do about these directly. One __divi64 is in apr_poll (convert microseconds to milliseconds. This can probably be optimized away). The other __divi64 is somewhere in cached_explode (util_time.c). The only division that I know of in cached_explode() is: struct exploded_time_cache_element *cache_element = (cache[seconds % TIME_CACHE_SIZE]); Is that where the division operation is being generated on your test system? TIME_CACHE_SIZE is 16, specifically so that the compiler can optimize away the division, but if there's still a division being generated, we can replace it with cache[seconds TIME_CACHE_MASK] --Brian
Re: cvs commit: apr/poll/unix pollacc.c Makefile.in poll.c
On 11 Jul 2002 15:32:18 -, [EMAIL PROTECTED] wrote: rbb 2002/07/11 08:32:18 Modified:.apr.dsp libapr.dsp poll/os2 Makefile.in poll/unix Makefile.in poll.c Added: poll/os2 pollacc.c poll/unix pollacc.c Log: Split the apr_poll() implementation from the accessor functions. This allows all platforms to use the same implementation for the accessor functions. Thanks, I've just committed what I have which gives me a working server again, even with multiple Listen's :) -- __ | Brian Havard | He is not the messiah! | | [EMAIL PROTECTED] | He's a very naughty boy! - Life of Brian | --
RE: [PATCH 2] example binary BUSEC patch for benchmarking only
At 10:41 AM 7/11/2002, Brian Pane wrote: On Thu, 2002-07-11 at 06:58, Bill Stoddard wrote: I ran a quick profile with this patch and it eliminated a couple of divisions (calls to __divi64 reduced from 4 to 2 in my test setup. your mileage may vary) which was good for 493 instructions. Still have 3 __divu64 and 2 __divi64 calls. The three __divu64 calls are in the gettimeofday() CRT function, so there is not much we can do about these directly. One __divi64 is in apr_poll (convert microseconds to milliseconds. This can probably be optimized away). The other __divi64 is somewhere in cached_explode (util_time.c). The only division that I know of in cached_explode() is: struct exploded_time_cache_element *cache_element = (cache[seconds % TIME_CACHE_SIZE]); Is that where the division operation is being generated on your test system? Actually, we still have division on construct busec from usecs. That would be the one /100 which can never be optimized away. Fortunately, it should be infrequent. Bill
Re: [PATCH 2] example binary BUSEC patch for benchmarking only
On Thu, 11 Jul 2002, Greg Marr wrote: I keep thinking that APR_USEC_PER_SEC should be (1 20), or now (1 APR_USEC_BITS) instead of the magical constant. I have no way of verifying with a quick glance that 1048576 is really 2^20. You don't know your powers of 2? Memorize, Greg, Memorize. ;)
[PATCH 3] example binary BUSEC for discussion
At 11:31 AM 7/11/2002, Brian Pane wrote: I don't see a way to eliminate the / 1000 to convert usec to msec. But we may be able to do all the math in 32-bit mode, by limiting the maximum timeout to the number of milliseconds that will fit in 32 bits, which works out to a max timeout of about 50 days. Actually, here is my current math, with optimized forms for specific situations we encounter often (aprox. limits are given in the macro name). They break down to; apr_int32_t apr_time_sec_get(time) deprecates apr_time_sec(time) apr_int32_t apr_time_msec_get(time) deprecates apr_time_msec(time) apr_int32_t apr_time_usec_get(time) deprecates apr_time_usec(time) apr_int32_t apr_time_nsec_get(time) deprecates apr_time_nsec(time) apr_int64_t apr_time_as_sec(time) apr_int64_t apr_time_as_msec(time) or apr_time_as_272yrs_msec(time) apr_int64_t apr_time_as_usec(time) or apr_time_as_3mos_usec(time) apr_int64_t apr_time_as_nsec(time) or apr_time_as_2hrs_nsec(time) apr_time_t apr_time_mmake(sec, msec) apr_time_t apr_time_umake(sec, usec) apr_time_t apr_time_nmake(sec, nsec) apr_time_t apr_time_from_sec(sec) apr_time_t apr_time_from_msec(msec) or apr_time_from_3mos_msec(msec) apr_time_t apr_time_from_usec(usec) or apr_time_from_3mos_usec(usec) apr_time_t apr_time_from_nsec(nsec) or apr_time_from_3mos_nsec(nsec) The code follows, patch attached is hard to follow. [Like my code isn't :o] /* Number of binary microseconds per second is (2^20) * to keep the math fast and simple [binary arithmetic.] */ #define APR_BUSEC_BITS 20 #define APR_BUSEC_PER_SEC APR_TIME_C(2 ^ APR_BUSEC_BITS) /* apr_time_sec_get returns 32 bits and is subject to the Y2038 bug * @see apr_time_as_sec for 64 bit resolution */ #define apr_time_sec_get(time) ((apr_int32_t)((time) APR_BUSEC_BITS)) /* These functions 'get' the xsec fractional component of the time. * * msec extraction won't overflow 32 bits so convert early, * while usec/nsec computations must be in all 64 bit math. */ #define apr_time_msec_get(time) \ (((apr_int32_t)((time) (APR_BUSEC_PER_SEC - 1)) * 1000) \ APR_BUSEC_BITS) #define apr_time_usec_get(time) \ ((apr_int32_t)time) (APR_BUSEC_PER_SEC - 1)) \ * APR_TIME_C(100)) APR_BUSEC_BITS)) #define apr_time_nsec_get(time) \ ((apr_int32_t)time) (APR_BUSEC_PER_SEC - 1)) \ * APR_TIME_C(10)) APR_BUSEC_BITS)) /* apr_time_as_sec returns 64 bits and escapes the Y2038 bug * @see apr_time_sec_get for 32 bit resolution */ #define apr_time_as_sec(time) ((apr_int64_t)((time) APR_BUSEC_BITS)) /* These functions return the given time value, complete, * in the given resolution (not simply the fractional component) * * They carry no resolution penalty, and due to the binary math, * they suffer little performance penalty either. */ #define apr_time_as_msec(time) \ (((apr_int64_t)(time) APR_BUSEC_BITS) \ + apr_int32_t)(time) (APR_BUSEC_PER_SEC - 1)) \ * 1000) APR_BUSEC_BITS)) #define apr_time_as_usec(time) \ (((apr_int64_t)(time) APR_BUSEC_BITS) \ + apr_int64_t)(time) (APR_BUSEC_PER_SEC - 1)) \ * APR_TIME_C(100)) APR_BUSEC_BITS)) #define apr_time_as_nsec(time) \ (((apr_int64_t)(time) APR_BUSEC_BITS) \ + apr_int64_t)(time) (APR_BUSEC_PER_SEC - 1)) \ * APR_TIME_C(10)) APR_BUSEC_BITS)) /* this computation is alright, but not great, we are limited to 272 * years. No Y2038 bug, but consider it an 'optimized form' for which * we have some loss of resolution. Doing this in 32 bit signed math * would yield only 2 seconds, which is not worth implementing compared * to the existing apr_time_msec_get(). */ #define apr_time_as_272yrs_msec(time) \ (((apr_int64_t)(time) * APR_TIME_C(1000)) APR_BUSEC_BITS) /* Another optimized form, we are limited to some 101 days. * Consider it a bleeding optimization with a great loss of resolution. */ #define apr_time_as_3mos_usec(time) \ (((apr_int64_t)(time) * APR_TIME_C(100)) APR_BUSEC_BITS) /* The final optimized form, we are limited to some 2.44 hours. * Use with extreme care. */ #define apr_time_as_2hrs_nsec(time) \ (((apr_int64_t)(time) * APR_TIME_C(10)) APR_BUSEC_BITS) /* These have no loss of resolution if the 2nd xsec arg is 1second */ #define apr_time_mmake(sec, msec) ((apr_time_t)(sec) APR_BUSEC_BITS \ + ((apr_time_t)(msec) APR_BUSEC_BITS) / APR_TIME_C(1000)) #define apr_time_umake(sec, usec) ((apr_time_t)(sec) APR_BUSEC_BITS \ + ((apr_time_t)(usec) APR_BUSEC_BITS) / APR_TIME_C(100)) #define apr_time_nmake(sec, nsec) ((apr_time_t)(sec) APR_BUSEC_BITS \ + ((apr_time_t)(nsec) APR_BUSEC_BITS) / APR_TIME_C(10)) #define apr_time_from_sec(sec) ((apr_time_t)(sec) APR_BUSEC_BITS) /* These carry no resolution penalty, just a nasty performance penalty. */ #define apr_time_from_msec(msec) \
Re: cvs commit: apr STATUS
At 11:37 AM 7/11/2002, you wrote: brianp 2002/07/11 09:37:50 Modified:.STATUS Log: Added vote on apr_time_t naming 2) Renaming the function to get rid of apr_time_t vs time_t confusion, which wrowe suggests apr_butime_t [binary microtime]. +1: fielding -0: wrowe -0.5: rbb + -1: brianp [-1 for the apr_butime_t name specifically: let's + keep the type name independent of the internal + representation, so that we don't have to + change the name the next time we change the + implementation. I'd prefer something like + apr_timeval_t, but I can live with apr_time_t.] You have a huge falacy there. There is no way to change the definition without breaking binary compatibility. Since we are committed [on a go forward] to binary compatibility, this definition will not be changing anytime before 1.0, then before 2.0. So whatever we do, it will be quite stable. But I vote on the apr_time_t side, so it makes no nevermind here :) Bill
Re: [PATCH 3] example binary BUSEC for discussion
William A. Rowe, Jr. wrote: At 11:31 AM 7/11/2002, Brian Pane wrote: I don't see a way to eliminate the / 1000 to convert usec to msec. But we may be able to do all the math in 32-bit mode, by limiting the maximum timeout to the number of milliseconds that will fit in 32 bits, which works out to a max timeout of about 50 days. Actually, here is my current math, with optimized forms for specific situations we encounter often (aprox. limits are given in the macro name). They break down to; apr_int32_t apr_time_sec_get(time) deprecates apr_time_sec(time) apr_int32_t apr_time_msec_get(time) deprecates apr_time_msec(time) apr_int32_t apr_time_usec_get(time) deprecates apr_time_usec(time) apr_int32_t apr_time_nsec_get(time) deprecates apr_time_nsec(time) Oh no, I just recently finished changing all the code to use those now-deprecated macros. :-) apr_int64_t apr_time_as_sec(time) apr_int64_t apr_time_as_msec(time) or apr_time_as_272yrs_msec(time) apr_int64_t apr_time_as_usec(time) or apr_time_as_3mos_usec(time) apr_int64_t apr_time_as_nsec(time) or apr_time_as_2hrs_nsec(time) The naming convention is way too subtle: apr_time_[unit]_get means 32-bit apr_time_as_[unit] means 64-bit How often do you anticipate that people will be using the 32-bit versions? If it's not very often, then I'd rather just supply the 64-bit versions in the API, because those are the safe ones (no Y2038 problem). People who really need to do 32-bit math for performance reasons would have to cast explicitly, but IMHO that's good because it forces them to think more carefully about whether the loss of precision is safe. --Brian
Re: cvs commit: apr STATUS
Just to clarify the technical reason for vetoing the use of apr_time_t with a new implementation. The reason I veto this is because I don't want us to maintain binary compatibility while we're not maintaining semantic compatibility. There are programs out there that use APR's apr_time_t and will treat them as decimals. This will result in very subtle timing bugs that will be *very* hard to track down. Since we're coming up with a new interface (as well as a new implementation) it needs to have a new name. -aaron On Thu, Jul 11, 2002 at 07:10:53PM -, [EMAIL PROTECTED] wrote: aaron 2002/07/11 12:10:53 Modified:.STATUS Log: These two questions aren't orthogonal, so the votes don't all make sense. But here are my votes anyway. Revision ChangesPath 1.137 +4 -2 apr/STATUS Index: STATUS === RCS file: /home/cvs/apr/STATUS,v retrieving revision 1.136 retrieving revision 1.137 diff -u -r1.136 -r1.137 --- STATUS 11 Jul 2002 19:03:25 - 1.136 +++ STATUS 11 Jul 2002 19:10:53 - 1.137 @@ -66,9 +66,11 @@ system types, or map to system units. +1: rbb, wrowe, jerenkrantz +0: brianp + -1: aaron [veto for reusing the apr_time_t identifier for a new use. +I'm ok with apr_timeval_t.] 2) Renaming the function to get rid of apr_time_t vs time_t confusion, which wrowe suggests apr_butime_t [binary microtime]. - +1: fielding + +1: fielding, aaron -0: wrowe, jerenkrantz -0.5: rbb -1: brianp [-1 for the apr_butime_t name specifically: let's
Re: [PATCH 3] example binary BUSEC for discussion
At 02:49 PM 07/11/2002, William A. Rowe, Jr. wrote: The code follows, patch attached is hard to follow. [Like my code isn't :o] /* Number of binary microseconds per second is (2^20) * to keep the math fast and simple [binary arithmetic.] */ #define APR_BUSEC_BITS 20 #define APR_BUSEC_PER_SEC APR_TIME_C(2 ^ APR_BUSEC_BITS) Thanks, but (2 ^ APR_BUSEC_BITS) is 22 (^ is XOR). You want 1 APR_BUSEC_BITS. -- Greg Marr [EMAIL PROTECTED] We thought you were dead. I was, but I'm better now. - Sheridan, The Summoning
Re: [PATCH 3] example binary BUSEC for discussion
At 02:13 PM 7/11/2002, Brian Pane wrote: William A. Rowe, Jr. wrote: apr_int32_t apr_time_sec_get(time) deprecates apr_time_sec(time) apr_int32_t apr_time_msec_get(time) deprecates apr_time_msec(time) apr_int32_t apr_time_usec_get(time) deprecates apr_time_usec(time) apr_int32_t apr_time_nsec_get(time) deprecates apr_time_nsec(time) Oh no, I just recently finished changing all the code to use those now-deprecated macros. :-) I know... but there are two different 'things'... apr_int64_t apr_time_as_sec(time) apr_int64_t apr_time_as_msec(time) or apr_time_as_272yrs_msec(time) apr_int64_t apr_time_as_usec(time) or apr_time_as_3mos_usec(time) apr_int64_t apr_time_as_nsec(time) or apr_time_as_2hrs_nsec(time) The naming convention is way too subtle: apr_time_[unit]_get means 32-bit apr_time_as_[unit] means 64-bit WRONG! apr_time_msec_get(time) gets the fractional component of time... e.g. 32500.15 seconds would return 150 msecs.. apr_time_as_msec returns the entire time value! So we end up with a time of 32,500,150 in msec's. That's why these are int64. How often do you anticipate that people will be using the 32-bit versions? If it's not very often, then I'd rather just supply the 64-bit versions in the API, because those are the safe ones (no Y2038 problem). People who really need to do 32-bit math for performance reasons would have to cast explicitly, but IMHO that's good because it forces them to think more carefully about whether the loss of precision is safe. The 32bit flavor of sec, vs. a 64 bit flavor is a simple way of avoiding casts in the user's code. I'm only asking for the number of seconds in an apr_time_t in order to set a time, calculate a difference, etc. But I don't care too much, one way or the other. apr_time_as_sec gives me a HUGE number of seconds to work with as an absolute time from 1/1/70. That must remain 64bit. Bill
Re: cvs commit: apr STATUS
At 02:20 PM 7/11/2002, Aaron Bannert wrote: Just to clarify the technical reason for vetoing the use of apr_time_t with a new implementation. The reason I veto this is because I don't want us to maintain binary compatibility while we're not maintaining semantic compatibility. There are programs out there that use APR's apr_time_t and will treat them as decimals. In this case, semantic compatibility has NO IMPACT on binary compatibility. The code will remain binary compatible, even though this change breaks the behavior. APR changes... we are pre-1.0 and our developer/consumers know it. The only SEMANTIC argument for a different name is Roy's observation that time_t v.s. apr_time_t confuses users into trying to directly set seconds instead of apr_time_t units. That's an argument I haven't bought into, but it is a legitimate argument. Bill
POLL havoc
Are the poll changes done (cvs update of 20.20 UTC): /usr/bin/ld: Undefined symbols: _apr_poll_revents_get _apr_poll_setup _apr_poll_socket_add _apr_poll_socket_clear _apr_poll_socket_mask _apr_poll_socket_remove _apr_socket_from_file and should I go try and fix the above on BSD/MacOSX - or did I catch things in the middle of an update sequence ? DW.
RE: POLL havoc
Did you re-run ./configure? Ryan -- Ryan Bloom [EMAIL PROTECTED] 645 Howard St. [EMAIL PROTECTED] San Francisco, CA -Original Message- From: Dirk-Willem van Gulik [mailto:[EMAIL PROTECTED] Sent: Thursday, July 11, 2002 1:24 PM To: dev@apr.apache.org Subject: POLL havoc Are the poll changes done (cvs update of 20.20 UTC): /usr/bin/ld: Undefined symbols: _apr_poll_revents_get _apr_poll_setup _apr_poll_socket_add _apr_poll_socket_clear _apr_poll_socket_mask _apr_poll_socket_remove _apr_socket_from_file and should I go try and fix the above on BSD/MacOSX - or did I catch things in the middle of an update sequence ? DW.
RE: POLL havoc
I do make distclean cvs update ./buildconf ./configure make is that enough ? Dw -- Dirk-Willem van Gulik On Thu, 11 Jul 2002, Ryan Bloom wrote: Did you re-run ./configure? Ryan -- Ryan Bloom [EMAIL PROTECTED] 645 Howard St. [EMAIL PROTECTED] San Francisco, CA -Original Message- From: Dirk-Willem van Gulik [mailto:[EMAIL PROTECTED] Sent: Thursday, July 11, 2002 1:24 PM To: dev@apr.apache.org Subject: POLL havoc Are the poll changes done (cvs update of 20.20 UTC): /usr/bin/ld: Undefined symbols: _apr_poll_revents_get _apr_poll_setup _apr_poll_socket_add _apr_poll_socket_clear _apr_poll_socket_mask _apr_poll_socket_remove _apr_socket_from_file and should I go try and fix the above on BSD/MacOSX - or did I catch things in the middle of an update sequence ? DW.
Re: cvs commit: apr STATUS
On Thu, Jul 11, 2002 at 02:35:04PM -0500, William A. Rowe, Jr. wrote: In this case, semantic compatibility has NO IMPACT on binary compatibility. The code will remain binary compatible, even though this change breaks the behavior. APR changes... we are pre-1.0 and our developer/consumers know it. The only SEMANTIC argument for a different name is Roy's observation that time_t v.s. apr_time_t confuses users into trying to directly set seconds instead of apr_time_t units. That's an argument I haven't bought into, but it is a legitimate argument. The problem is that it used to be completely valid to treat apr_time_t as a 64bit decimal integer quantity. Suddenly we are revoking that assumption, without effecting some sort of source-level change that will make the change obvious. Unfortunately for our users, the compiler will happily validate this code, even though the semantic has changed, and the user will not be notified of a potential problem. Let's take a typical scenario: - Acme software releases mod_acme 2.0 to work with Apache 2.0 - They distribute a binary version of this module to work specifically with 2.0.39 (the only version out that isn't susceptible to the chunked-encoding vulnerability). - Apache 2.0.40 is released, includes the new binary usec impl. - Acme customers upgrade their servers to 2.0.40 - Acme customers experience all sorts of weird timing issues, hung connections (which are really just timeouts that were translated to busec's), etc... -aaron
RE: POLL havoc
Yes, that is enough. The changes are done, and since Mac OS/X is using the standard Unix version, you shouldn't be having any problems. Make sure that your Makefile in poll/unix references pollacc.lo, because it doesn't look like it does. Ryan I do make distclean cvs update ./buildconf ./configure make is that enough ? Dw -- Dirk-Willem van Gulik On Thu, 11 Jul 2002, Ryan Bloom wrote: Did you re-run ./configure? Ryan -- Ryan Bloom [EMAIL PROTECTED] 645 Howard St. [EMAIL PROTECTED] San Francisco, CA -Original Message- From: Dirk-Willem van Gulik [mailto:[EMAIL PROTECTED] Sent: Thursday, July 11, 2002 1:24 PM To: dev@apr.apache.org Subject: POLL havoc Are the poll changes done (cvs update of 20.20 UTC): /usr/bin/ld: Undefined symbols: _apr_poll_revents_get _apr_poll_setup _apr_poll_socket_add _apr_poll_socket_clear _apr_poll_socket_mask _apr_poll_socket_remove _apr_socket_from_file and should I go try and fix the above on BSD/MacOSX - or did I catch things in the middle of an update sequence ? DW.
Re: POLL havoc
On Thu, Jul 11, 2002 at 09:55:39PM +0200, [EMAIL PROTECTED] wrote: make distclean cvs update ./buildconf ./configure make check your exports.c and export_vars.h files for the old definitions. -aaron
Fwd: Re: [PATCH 3] example binary BUSEC for discussion
I'm assuming this was meant for the whole list. :) From: William A. Rowe, Jr. [EMAIL PROTECTED] Subject: Re: [PATCH 3] example binary BUSEC for discussion At 02:18 PM 7/11/2002, you wrote: At 02:49 PM 07/11/2002, William A. Rowe, Jr. wrote: The code follows, patch attached is hard to follow. [Like my code isn't :o] /* Number of binary microseconds per second is (2^20) * to keep the math fast and simple [binary arithmetic.] */ #define APR_BUSEC_BITS 20 #define APR_BUSEC_PER_SEC APR_TIME_C(2 ^ APR_BUSEC_BITS) Thanks, but (2 ^ APR_BUSEC_BITS) is 22 (^ is XOR). You want 1 APR_BUSEC_BITS. Shoot. [Bang.] Can everyone playing make this fix themselves for a little bit? I have one patch to write for the guts of NT (which plays in 100ns time units) to mirror the new patch. I'll post both together a bit later. Bill -- Greg Marr [EMAIL PROTECTED] We thought you were dead. I was, but I'm better now. - Sheridan, The Summoning
[PATCH] Test cases for apr_vformatter and apr_snprintf
Me and Sander Striker made a deal. He and I decided to fix
apr_psprintf the same way - including the removal of the older fix
in apr_vformatter. So, Sander is going to fix and commit the
apr_psprintf and apr_vformatter things - and I am going to supply the
testcases to make sure apr_vformatter and apr_snprintf work like I
assume they would. Note that there's no test for apr_psprintf
working. But, here they are.
* Test cases for apr_vformatter and apr_snprintf. Both are tested for
in three cases - normal usage, just filling the buffer and
overflowing the buffer.
Patch:
diff --exclude=CVS -Nur apr.old/test/Makefile.in apr/test/Makefile.in
--- apr.old/test/Makefile.inFri Jul 5 11:49:55 2002
+++ apr/test/Makefile.inWed Jul 10 23:37:29 2002
@@ -46,7 +46,8 @@
[EMAIL PROTECTED]@ \
[EMAIL PROTECTED]@ \
[EMAIL PROTECTED]@ \
- [EMAIL PROTECTED]@
+ [EMAIL PROTECTED]@ \
+ [EMAIL PROTECTED]@
TARGETS = $(PROGRAMS) $(NONPORTABLE)
@@ -203,5 +204,8 @@
[EMAIL PROTECTED]@: testtable.lo $(LOCAL_LIBS)
$(LINK) testtable.lo $(LOCAL_LIBS) $(ALL_LIBS)
+
[EMAIL PROTECTED]@: testsnprintf.lo $(LOCAL_LIBS)
+ $(LINK) testsnprintf.lo $(LOCAL_LIBS) $(ALL_LIBS)
# DO NOT REMOVE
diff --exclude=CVS -Nur apr.old/test/testsnprintf.c apr/test/testsnprintf.c
--- apr.old/test/testsnprintf.c Thu Jan 1 02:00:00 1970
+++ apr/test/testsnprintf.c Thu Jul 11 22:56:58 2002
@@ -0,0 +1,241 @@
+/*
+ * The Apache Software License, Version 1.1
+ *
+ * Copyright (c) 2000-2002 The Apache Software Foundation. All rights
+ * reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ *
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in
+ *the documentation and/or other materials provided with the
+ *distribution.
+ *
+ * 3. The end-user documentation included with the redistribution,
+ *if any, must include the following acknowledgment:
+ * This product includes software developed by the
+ *Apache Software Foundation (http://www.apache.org/).
+ *Alternately, this acknowledgment may appear in the software itself,
+ *if and wherever such third-party acknowledgments normally appear.
+ *
+ * 4. The names Apache and Apache Software Foundation must
+ *not be used to endorse or promote products derived from this
+ *software without prior written permission. For written
+ *permission, please contact [EMAIL PROTECTED]
+ *
+ * 5. Products derived from this software may not be called Apache,
+ *nor may Apache appear in their name, without prior written
+ *permission of the Apache Software Foundation.
+ *
+ * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
+ * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+ * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
+ * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
+ * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
+ * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
+ * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ *
+ *
+ * This software consists of voluntary contributions made by many
+ * individuals on behalf of the Apache Software Foundation. For more
+ * information on the Apache Software Foundation, please see
+ * http://www.apache.org/.
+ */
+
+#include assert.h
+#include stdlib.h
+#include string.h
+
+#include apr_general.h
+#include apr_strings.h
+#include apr_lib.h
+
+static int test_flush(apr_vformatter_buff_t *vbuff)
+{
+return -1;
+}
+
+static int call_vformatter(apr_pool_t *p, apr_vformatter_buff_t *vbuff, const
char *format, ...)
+{
+ int cc;
+ va_list ap;
+
+ va_start(ap, format);
+ cc = apr_vformatter(test_flush, vbuff, format, ap);
+ va_end(ap);
+ return cc;
+}
+
+/*
+ * After a call to vformatter, curpos should be one past the last
+ * character written and return value should be the amount of
+ * characters written.
+ */
+static void test_vformatter1(apr_pool_t *p)
+{
+ apr_vformatter_buff_t vbuff;
+ char *testbuf;
+ int cc;
+
+ /* Make room for 8 character */
+ testbuf = apr_palloc(p, 8);
+ /* But endpos is never written, so we only have 7 to use. */
+
Re: [PATCH] fixes for apr_vformatter and apr_snprintf
Jim Jagielski wrote: After that apr_snprintf returns len-1 if the data just fit and len if it got truncated. Is this what is wanted? It would appear so... Certainly not being able to tell truncation from it just fit is non-ideal. Well yes. But now that we have really decided on the behaviour, someone should change the documentatoin. The kludge is the (sp = beg)...INS_CHAR... stuff right before we return cc though, right? Want to make sure that's the code you're referring to :) Yes, the unnecessary flushing at the end. But, see my other mail - me and Sander basically split the handling of this issue. -- Naked
Re: cvs commit: apr STATUS
William A. Rowe, Jr. wrote: At 11:37 AM 7/11/2002, you wrote: brianp 2002/07/11 09:37:50 Modified:.STATUS Log: Added vote on apr_time_t naming 2) Renaming the function to get rid of apr_time_t vs time_t confusion, which wrowe suggests apr_butime_t [binary microtime]. +1: fielding -0: wrowe -0.5: rbb + -1: brianp [-1 for the apr_butime_t name specifically: let's + keep the type name independent of the internal + representation, so that we don't have to + change the name the next time we change the + implementation. I'd prefer something like + apr_timeval_t, but I can live with apr_time_t.] You have a huge falacy there. There is no way to change the definition without breaking binary compatibility. Since we are committed [on a go forward] to binary compatibility, this definition will not be changing anytime before 1.0, then before 2.0. I'm not worried about breaking binary compatibility; I'm worried about breaking source compatibility. In 2.0, if we change the implementation, we can make it backward compatible (at the source level, not binary) with all the existing application code by updating the macros--unless we have to change the type name because the 1.0 name was tied to the old implementation. --Brian
More recent ./configure entertainment
Hmm - on MacOSX 10.1.5 - one for the autoconf experts..
cvs co apr; cd apr
./configure
..
checking for mmap that can map /dev/zero... no
decision on anonymous shared memory allocation method... 4.4BSD-style
mmap() via MAP_ANON
decision on namebased memory allocation method... SysV IPC shmget()
checking for calloc... yes
.
make make install
== all happy
but:
$ cvs co httpd-2.0
$ cd srclib
$ cvs co apr apr-util
$ ./configure
Cecking for os2.h... no
/Users/dirkx/ORA/httpd-2.0/srclib/apr/configure:Error: decision on
anonymous shared memory allocation method failed
srclib/apr configured properly
./configure: no such file or directory: ./srclib/apr/apr-config [2057]
./configure: no such file or director
And the above can be reproduced by doing a 'cat config.log in the above
to see how the httpd-2.0 configure starts the apr configure:
$ cvs co apr
$ cd apr
$ prefix=/foo /bar/httpd-2.0/srclib/apr/configure
--prefix=/foo --enable-auth-dbm --enable-auth-anon
--enable-access-dbm --enable-auth-digest
--enable-maintainer-mode --cache-file=/dev/null
--srcdir=/bar/httpd-2.0/apr --prefix=/foo
--exec-prefix=/foo --libdir=${prefix}/lib
--includedir=/foo/include
--bindir=${prefix}/bin
--datadir=/foo
--with-installbuilddir=${prefix}/build
So questions about the above; is it worrysome that we have --prefix in
there twice. And secondly that some still are ${prefix} i.e. not
substituted ? And finally - anything obviously wrong ?
Dw
Re: More recent ./configure entertainment
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
So questions about the above; is it worrysome that we have --prefix in
there twice. And secondly that some still are ${prefix} i.e. not
substituted ? And finally - anything obviously wrong ?
Dirk, I build APR/HTTPD on a daily basis with 10.1.5 and never saw the
problem you mentioned. I bet you're using the (screwed up) version of
AutoConf/AutoMake coming with the developer tools... I had to patch that one
as well...
Pier
--
[Perl] combines all the worst aspects of C and Lisp: a billion of different
sublanguages in one monolithic executable. It combines the power of C with
the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco]
Re: More recent ./configure entertainment
Dirk, I build APR/HTTPD on a daily basis with 10.1.5 and never saw the problem you mentioned. I bet you're using the (screwed up) version of AutoConf/AutoMake coming with the developer tools... I had to patch that one as well... Neither did I - until the day before yesterday and today ;-( .. but I've been using the same homebuild glibtool(ize) and homebuild autoconf since march with a little pach for the two level namespace thing. Perhaps time to do an update on everything to a recent version and do a fresh checkout. The only change I can find in the last three date is an update of sed and perl. Dw
Re: [PATCH 3] example binary BUSEC for discussion
Guys, everyone here admits we are lousy at inventing names... all suggestions for better names of these macros are welcome! At 01:49 PM 7/11/2002, William A. Rowe, Jr. wrote: Actually, here is my current math, with optimized forms for specific situations we encounter often (aprox. limits are given in the macro name). They break down to; apr_int32_t apr_time_sec_get(time) deprecates apr_time_sec(time) apr_int32_t apr_time_msec_get(time) deprecates apr_time_msec(time) apr_int32_t apr_time_usec_get(time) deprecates apr_time_usec(time) apr_int32_t apr_time_nsec_get(time) deprecates apr_time_nsec(time) apr_int64_t apr_time_as_sec(time) apr_int64_t apr_time_as_msec(time) or apr_time_as_272yrs_msec(time) apr_int64_t apr_time_as_usec(time) or apr_time_as_3mos_usec(time) apr_int64_t apr_time_as_nsec(time) or apr_time_as_2hrs_nsec(time) apr_time_t apr_time_mmake(sec, msec) apr_time_t apr_time_umake(sec, usec) apr_time_t apr_time_nmake(sec, nsec) apr_time_t apr_time_from_sec(sec) apr_time_t apr_time_from_msec(msec) or apr_time_from_3mos_msec(msec) apr_time_t apr_time_from_usec(usec) or apr_time_from_3mos_usec(usec) apr_time_t apr_time_from_nsec(nsec) or apr_time_from_3mos_nsec(nsec)
Re: cvs commit: apr STATUS
On 11 Jul 2002 [EMAIL PROTECTED] wrote: + -1: aaron [veto for reusing the apr_time_t identifier for a new use. +I'm ok with apr_timeval_t.] If we're avoiding apr_time_t because of confusion with the POSIX time_t, it makes no sense whatsoever to use apr_timeval_t either, since POSIX also defines struct timeval (with a seconds component and a usecs component). --Cliff
Re: cvs commit: apr STATUS
On Thu, Jul 11, 2002 at 01:37:14PM -0700, Brian Pane wrote: Let's take a typical scenario: - Acme software releases mod_acme 2.0 to work with Apache 2.0 - They distribute a binary version of this module to work specifically with 2.0.39 (the only version out that isn't susceptible to the chunked-encoding vulnerability). - Apache 2.0.40 is released, includes the new binary usec impl. - Acme customers upgrade their servers to 2.0.40 - Acme customers experience all sorts of weird timing issues, hung connections (which are really just timeouts that were translated to busec's), etc... I agree that this is a scenario that we need to avoid breaking. But changing the type name won't solve the problem: the run-time linker won't know the difference, since it doesn't know the types of fields inside structs or of function args. I think the way to fix the binary problem is to just increase the MMN major number. Bumping the MMN works for things like Apache, but not for flood, subversion, or any of the countless other APR-based apps that have sprung up lately. I'll agree that changing the typename doesn't solve the problem of mismatched binary compatibility, but it does make it obvious to the app author where the interface has changed. The renaming simply gives us compile-time type-checking. Maybe APR needs to have its own magic number. Is there a way to make a version check mandatory, or are we stuck with a voluntary check? -aaron
RE: cvs commit: apr STATUS
Bumping the MMN works for things like Apache, but not for flood, subversion, or any of the countless other APR-based apps that have sprung up lately. I'll agree that changing the typename doesn't solve the problem of mismatched binary compatibility, but it does make it obvious to the app author where the interface has changed. The renaming simply gives us compile-time type-checking. Maybe APR needs to have its own magic number. Is there a way to make a version check mandatory, or are we stuck with a voluntary check? Versioning has been on the todo list for a long time now. Perhaps the apr_time_t change is a good enough reason to add it ASAP. Then, we can do the versioning and the apr_time_t change at the same time, and this problem is solved completely. Ryan
Re: cvs commit: apr STATUS
Ryan Bloom wrote: Bumping the MMN works for things like Apache, but not for flood, subversion, or any of the countless other APR-based apps that have sprung up lately. I'll agree that changing the typename doesn't solve the problem of mismatched binary compatibility, but it does make it obvious to the app author where the interface has changed. The renaming simply gives us compile-time type-checking. Maybe APR needs to have its own magic number. Is there a way to make a version check mandatory, or are we stuck with a voluntary check? Versioning has been on the todo list for a long time now. Perhaps the apr_time_t change is a good enough reason to add it ASAP. Then, we can do the versioning and the apr_time_t change at the same time, and this problem is solved completely. That would be an almost ideal solution: * Keep the apr_time_t name to eliminate the number of code changes required * Add versioning to prevent a run-time mismatch of new lib and old app We'd still have the problem of compile-time mismatches: e.g., old code that does time / 100. But based on my recent experience in adding the new time macros in the httpd code, such constructs appear to be so rare that I'm willing to solve the problem with documentation rather than code. --Brian
