Re: [PATCH] apr_file_writev() on UNIX

2004-10-06 Thread Jean-Jacques Clar
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

Re: [PATCH] apr_file_writev() on UNIX

2004-10-06 Thread Jean-Jacques Clar
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

[PATCH] apr_file_writev() on UNIX

2004-10-05 Thread Jean-Jacques Clar
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:

Re: [PATCH] apr_file_writev() on UNIX

2004-10-05 Thread Jean-Jacques Clar
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)) !=

Re: [PATCH] apr_file_writev() on UNIX

2004-10-05 Thread Jean-Jacques Clar
[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

Re: cvs commit: apr/network_io/win32 sendrecv.c

2004-10-01 Thread Jean-Jacques Clar
"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

DWORD_MAX (was: cvs commit: apr/include apr.hnw)

2004-09-24 Thread Jean-Jacques Clar
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

Re: cvs commit: apr/include apr_atomic.h

2004-09-02 Thread Jean-Jacques 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

Re: cvs commit: apr_buckets_alloc.c

2004-08-10 Thread Jean-Jacques Clar
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 =

Re: cvs commit: apr/threadproc/netware proc.c

2004-07-12 Thread Jean-Jacques Clar
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

Re: cvs commit: apr/threadproc/netware proc.c

2004-07-09 Thread Jean-Jacques Clar
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

broken pipe (was:Re: 1.0.0.rc2 tarballs now ready...)

2004-07-01 Thread Jean-Jacques Clar
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

Re: 1.0.0.rc2 tarballs now ready...

2004-06-30 Thread Jean-Jacques Clar
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

broken pipe (was:Re: 1.0.0.rc2 tarballs now ready...)

2004-06-30 Thread Jean-Jacques Clar
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

[PROPOSAL] cgi_exec_info_t: detached addrspace fields combined

2004-06-24 Thread Jean-Jacques Clar
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

Re: cvs commit: apr/include apr_thread_proc.h

2004-06-15 Thread Jean-Jacques Clar
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

[PATCH]: APR_FROM_OS_ERROR on NetWare

2004-03-15 Thread Jean-Jacques Clar
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

[PATCH] check NULL in apr_bucket_alloc

2003-09-02 Thread Jean-Jacques Clar
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

Re: [PATCH] bucket debugging.

2003-08-14 Thread Jean-Jacques Clar
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. :)

Re: remaining issues prior to 1.0?

2003-06-26 Thread Jean-Jacques Clar
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

APR and Apache Time Format Questions

2003-03-03 Thread Jean-Jacques Clar
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

[PATCH] small optimization in ap_meets_conditions() and questions

2003-02-27 Thread Jean-Jacques Clar
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..

RE: memory leak in apr_buck_alloc...

2002-09-10 Thread Jean-Jacques Clar
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