that it is going to fail every single
time?
Is the current implementation meets the expectation of others and
I am the only one that see something wrong here?
Thanks,
Jean-Jacques
Joe Orton [EMAIL PROTECTED] 10/05/04 2:40 PM
On Tue, Oct 05, 2004 at 11:23:35AM -0600, Jean-Jacques Clar wrote: [EMAIL
Joe Orton [EMAIL PROTECTED] 10/06/04 12:46 PM
On Wed, Oct 06, 2004 at 10:12:33AM -0600, Jean-Jacques Clar wrote: As far as not having a bug in the !HAS_WRITEV implementation, I disagree. The current implementation does not have a single chance of being successful if there is more than 1 vector
IfHAS_WRITEV is not defined the current code
will just push the first vector to the target.
The function should write all the vectors or none.
I propose the following patch, comments will be
appreciated:
Thanks for looking.
JJ
Index:
Cliff Woolley [EMAIL PROTECTED] 10/04/04 7:08 PM
+ *nbytes = vec[i].iov_len;Is there really a point to the above line? *nbytes will always beoverwritten before returning anyway, so why not just skip this line andthen: + if ((rv = apr_file_write(thefile, vec[i].iov_base, nbytes)) !=
[EMAIL PROTECTED] 10/05/04 12:16 AM
On Mon, Oct 04, 2004 at 06:11:57PM -0600, Jean-Jacques Clar wrote: If HAS_WRITEV is not defined the current code will just push the first vector to the target. The function should write all the vectors or none.There is no guarantee that writev(2) writes all
"William A. Rowe, Jr." [EMAIL PROTECTED] 09/28/04 5:10 PM
#ifdef DWORD_MAX#define APR_DWORD_MAX DWORD_MAX#else#define DWORD_MAX 4294967295UL#endifWhat about:
#ifndef DWORD_MAX#define DWORD_MAX 4294967295UL /* 2^32*/#endif
#define APR_DWORD_MAX DWORD_MAX
I will be more than happy to do so, but first
will like to ask Allan to grant me permission
to APRizethe definein apr.hw, win32\sendrecv.c,
and win32\readwrite.c.
Thanks,
JJ "William A. Rowe, Jr." [EMAIL PROTECTED] 09/24/04 10:48 AM
At 11:33 AM 9/24/2004, [EMAIL PROTECTED] wrote:clar
Sander,
Would please move the tag for 2.0.51-RC3 on apr_atomic.h.
The following change fixes a bug on NetWare. It is
in NetWare specific code.
Thanks,
JJ [EMAIL PROTECTED] 09/02/04 2:13 PM
clar 2004/09/02 13:13:32 Modified: include Tag: APR_0_9_BRANCH apr_atomic.h Log: Fixed apr_atomic_dec
Shouldn't the preproc directivesbe #if instead of #ifdef?
diff -u -r1.15 apr_buckets_alloc.c--- srclib/apr-util/buckets/apr_buckets_alloc.c22 Jun 2004 16:18:20 -1.15+++ srclib/apr-util/buckets/apr_buckets_alloc.c10 Aug 2004 20:27:58 -@@ -53,7 +53,7 @@ apr_allocator_t *allocator =
3- overload detach field from cgi_exec_info_t in 2.0 to make sure no bump are needed, no backport entry needed in that case.Not sure what you mean there, any proposed backport to theAPACHE_2_0_BRANCH for httpd needs to be added to STATUS following thenormal procedure.The change done in 2.1
used as a bitfield like this in the 2.0 branch. For mod_cgi in HEAD itneedn't be weird of course, the addrspace field could be left in there.I was trying to make head and 2.0 the same,
my bet for not disconnectingthe twobranches...
To do:
1-pull back today head httpd and apr changes, it is
The problem is in our own library. The recent changes cause itto
don't catch the end of the generated file and go on reading it until
the read fails.
In 2.1 previous tomod_cgi.c:r1.153
the return value of ap_pass_brigade() was not checked in
include_cmd(), but now it is done. That change
I am getting the following error when running CGIs on the current
version of NetWare (6.5 sp2):
(32)Broken pipe: ap_content_length_filter: apr_bucket_read() failed
I am working on tracking down the problem.
JJ "David Reid" [EMAIL PROTECTED] 6/30/2004 10:00:52 AM
So, I fixed the incorrect tag
I am getting the following error when running CGIs on the current
version of NetWare (6.5 sp2):
(32)Broken pipe: ap_content_length_filter: apr_bucket_read() failed
I am working on tracking down the problem.
Changes done to mod_cgi.c, mod_include.(h c) back in August 22, 2003
are exposinga
To replace the addrspace field that was added in the cgi_exec_info_t
struct in mod_cgi.hI will like to propose extendingthe use of the
detached (apr_int32_t) field in cgi_exec_info_t and apr_procattr_t structs.
Currently that field is set to 0 by default and1 if the process to be
created will
Default is no-op on every platform except for NetWare which is NO. By default we want to run
child in the currentaddress space, the same as the parent process instead of using separate ones.
Performance and complexity are twomain reasons.
This is something specific to the NetWare OS that will
The attached patch ensure that APR_FROM_OS_ERROR(e) return
a consistent value for NetWare.
Thecurrent macro preventsAB to runon NetWare because
we are failing a test in apr_socket_connect():
sockets.c (line 356)
if (connect(sock-socketdes, (const struct
In thecase thata server is running out of memory (yeah, I know it never happens),
apr_allocator_alloc()is returning NULL, but it is never checked for in apr_bucket_alloc().
Doesthe bucket allocfunctionshould pass that NULL back to the
function/application asking for memory?
Thanks,
JJ
thanks, now building... Cliff Woolley [EMAIL PROTECTED] 8/13/2003 5:42:17 PM
On Wed, 13 Aug 2003, Jean-Jacques Clar wrote: Am I missing something in the patch I have? I don't find the implementation of the two APR_RING_CHECK macros.cvs up. :)
Cliff,
I will really love to see the implementation of the
apr_bucket_alloc_create_ex()
taking an actual allocator as a parameter and setting themax_free
limit on it
before releasing 1.0.
This shouldput an end to the bucket_max_free() saga...
Let me know if I could help.
Thank you,
JJ
I have two Questions/Suggestions to improve the current performance
of Apache 2.
1:
Apache and Apr are keeping the time stamp in uSEC, it implies multiple
calls to apr_time_sec(), which is just doing a 64 bits division to
transform
uSEC in sec.
I think this is a waste of CPU cycles for
Since the target value is in second, it should be possible to use
r-request_time instead of calling apr_time_now().
I ran a load test on my box and did not ever see a difference between the
sec value in r-request_time and the one returned by apr_time_now().
end of the patchpart..
I think I have been seeing the same thing for a long time when
refreshing entries
in mod_mem_cache. If you find something in the alloc path I
will be
more than happy to try it in my lab.
"Jean-Jacques Clar" [EMAIL PROTECTED] on 05/21/2002 06:23:58
PMTo: W G
Stoddard/Rale
23 matches
Mail list logo