Re: Poor performance with new apr_pool

Jim Jagielski wrote: On Apr 8, 2009, at 8:33 PM, Jeff Trawick wrote: On Wed, Apr 8, 2009 at 11:00 AM, Jim Jagielski wrote: On Mar 30, 2009, at 3:02 PM, Jim Jagielski wrote: Yep... I will try to recreate on Ubuntu in addition to the OS X testing. OK This seems unrelated (maybe) to the

Re: APR failing in low memory situations

M Joonas Pihlaja wrote: Hi list, I ran into a problem where a program I'm working on was segfaulting when calling apr_hash_set() due to memory exhaustion. So I was going to ask if we can have a version of apr_hash_set() which could return a status code if it fails to add a value to a hash. Havi

Re: [PATCH] speed up apr_pollset_remove

Greg Ames wrote: the basic idea is to exploit the fact that the internal pfd_elem_t and apr_pollfd_t occupy the same chunk of memory. by twiddling the internal structure, the pointer to one is the pointer to both and no search is needed. I'd suggest adding this comment to the source code;

Re: 2.0 branch?

William A. Rowe, Jr. wrote: david reid wrote: Given the talk over last few days about changes to error handling and the io abstraction stuff, is it time to think about starting a 2.0 development branch? -1 to creating a 2.0 branch. +1 to branching 1.x anytime someone gets the urge. Forward

Re: [PROPOSAL/PATCH] add ssl sockets

William A. Rowe, Jr. wrote: Jeff Trawick wrote: On 6/13/06, david reid <[EMAIL PROTECTED]> wrote: The attached patch is a first pass at getting some support for using openssl directly for ssl sockets within APR. I've tried to be generic in the basic configure code, but the actaul guts are basi

Re: [Fwd: apr/win32 misinterpreted the meaning of WAIT_ABANDONED]

se two routines should return APR_SUCCESS in this case, not APR_BUSY. [Bill Stoddard] However, we shouldn't return APR_BUSY either. The normal proper way to handle WAIT_ABANDONED is to put the WaitForSingleObject() (or any other equivalent API) in a loop, e.g.:

Re: Bandwidth Limit on Windows

William A. Rowe, Jr. wrote: Bill Stoddard wrote: My thinking on how to solve this has changed over the past year or so... there are numerous ways to DoS an httpd server and you can't protect against the more effective attacks at the httpd layer. I forgot the punch line here but hope

Re: Bandwidth Limit on Windows

My thinking on how to solve this has changed over the past year or so... there are numerous ways to DoS an httpd server and you can't protect against the more effective attacks at the httpd layer. I forgot the punch line here but hopefully it's obvious where I'm heading... apr_sendfile on win

Re: Bandwidth Limit on Windows

William A. Rowe, Jr. wrote: Phillip Susi wrote: When I asked about this a month or two ago, someone explained that Apache uses TransmitFile() to implement sendfile but in a weird way that makes it really, really slow. Disabling sendfile in the apache config, and just using the mmap module gi

Re: [VOTE] APR 1.2.0

E Holyat wrote: Here is a patch for win32 that has been tested extensively for a few months now. I submitted it to bugzilla Based on a quick code review, I'm +1 for committing this patch. Bill

Re: pollset initialization within apr_file_open()?

Joe Orton wrote: On Sun, Jul 03, 2005 at 04:27:05PM -0700, Brian Pane wrote: I just did some performance profiling of httpd-2.1 for the first time in a long while. One of the odd things I noticed is that apr_file_open() appears to spend half its time in a call to apr_pollset_create(). Th

Re: [WIN32] alternative apr_pollset implementation proposal

William A. Rowe, Jr. wrote: This makes alot of sense. But we are talking about the need for large scale parallelism, not discrete events. Once a given unit of I/O work can be performed on a given socket or pipe, it's going to be time to farm it out to a worker. Somewhere in this scheme we need to

Re: [WIN32] alternative apr_pollset implementation proposal

Bill Stoddard wrote: Mladen Turk wrote: Hi, Since the WIN32 imposes pretty nasty limit on FD_SETSIZE to 64, that is way too low for any serious usage, I developed an alternative implementation. Also the code support the APR_POLLSET_THREADSAFE flag. A simple patch to apr_arch_poll_private.h allows

Re: [WIN32] alternative apr_pollset implementation proposal

Mladen Turk wrote: Hi, Since the WIN32 imposes pretty nasty limit on FD_SETSIZE to 64, that is way too low for any serious usage, I developed an alternative implementation. Also the code support the APR_POLLSET_THREADSAFE flag. A simple patch to apr_arch_poll_private.h allows to have multiple imple

Re: do we still want sendfile enabled with our default conf files?

Cliff Woolley wrote: On Fri, 18 Mar 2005, Ryan Bloom wrote: disabling sendfile solved it immediately. Seems to me that until our sendfile support is better, we should err on the side of always sending the data correctly instead of absolutely as fast as possible. I would much rather have APR defau

Re: svn commit: r124075 - /apr/apr/trunk/threadproc/unix/signals.c

This is well outside my current knowledge, so take this comment for what's its worth (probably not much)... Would it make more sense to properly set SIGPROCMASK_SETS_THREAD_MASK depending on whether APR_HAS_THREADS or not? Bill [EMAIL PROTECTED] wrote: Author: jfclere Date: Tue Jan 4 00:57:44 2

Re: 2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN migration complete

William A. Rowe, Jr. wrote: At 08:23 AM 11/20/2004, Jim Jagielski wrote: On Nov 20, 2004, at 12:03 AM, Justin Erenkrantz wrote: So, my opinion is that we let Allen branch apr off now and let him go at it at a measured pace, but we shouldn't intend to hold httpd 2.2 for that. -- justin +1. Of cour

Re: [Fwd: Re: Making pool 3 times faster on WIN32]

William A. Rowe, Jr. wrote: At 01:32 PM 9/1/2004, Mladen Turk wrote: Bill Stoddard wrote: Not sure what's the total httpd's time spent for palloc, but I suppose it's quite a large value. I saw no significant difference serving a 500 byte file: Keep in mind that the whole idea behi

[Fwd: Re: Making pool 3 times faster on WIN32]

Failed to cc dev@ --- Begin Message --- Mladen Turk wrote: Hi, If my tests are correct the following patch makes the pool allocation tree times faster on WIN32 (at least for 1 million 32 bytes allocations). Not sure what's the total httpd's time spent for palloc, but I suppose it's quite a large va

Re: [PATCH] RESEND: fixing condvar bug under WIN32

Gah, this 'little' project isn't so little :-) Should apr_thread_cond_* have the same semantics as the posix pthread_cond_* routines? If the answer is yes, then the Win32 implementation is going to be nasty (maybe nastier than it already is) and the performance is going to be rather bad ('rather

Re: [PATCH] RESEND: fixing condvar bug under WIN32

Klaus Keppler wrote: Hello! As I already mentioned many many many weeks ago, the implementation of condition variables under WIN32 has at least one nasty bug which may lead to a deadlock (see http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27654) In my application which uses APR I really *do* exp

Re: [PATCH] WIN32 Fix apr_stat obtaing protection info

Mladen Turk wrote: Hi, apr_stat fails obtaining protection cause APR_READCONTROL flag set on apr_file_open inside apr_stat is never used. The READ_CONTROL is needed cause GetSecurityInfo returns Access is denied otherwise. Tested both on files and dirs, and... one break less in testall :) Index: op

Re: RC6 take 2

David Reid wrote: new apr-util tarballs are now available at http://www.apache.org/~dreid/ So far I've seen only 1 +1 for a release. Anyone else care to vote? david +1 bill

Re: Commit MSVC++ fixes?

Ed Holyat wrote: My employer and myself have no problem with contributing to the foundation, but, the CLA is way to general. If it were revised to only include contributions towards a specific project it would be simple to sign and submit. I need to look but I believe the corporate CLA (which is

Re: Commit MSVC++ fixes?

Ed Holyat wrote: There was additional patches attached to the bug(30103) submitted by Craig Rodrigues - Changes to compile from inside of MSVC++ - Purified - They included run time errors from vars that were not initialized. - A change to the pipe test to fail the test before hanging the test suite

Re: Commit MSVC++ fixes?

Craig Rodrigues wrote: Hi, Can someone with commit privileges look at committing my MSVC++ fixes to the apr tests at: http://issues.apache.org/bugzilla/show_bug.cgi?id=30103 I've posted these fixes to the mailing list before. Thanks. Craig, I just committed this patch to APR HEAD. testall now compi

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

Justin Erenkrantz wrote: --On Thursday, July 22, 2004 7:30 AM -0400 Jeff Trawick <[EMAIL PROTECTED]> wrote: On a slightly more interesting note, I committed something to APR HEAD a few days ago and was faced with the question "darn, under what APR release number do I put the CHANGES entry?"... I

Re: cvs commit: apr-util/xlate xlate.c

This patch broke the build: http://cvs.apache.org/viewcvs.cgi/apr-util/xlate/xlate.c?r1=1.17.2.1&r2=1.17.2.2 API to apr_iconv_open/close was changed about three years ago by this patch: http://cvs.apache.org/viewcvs.cgi/apr-iconv/lib/iconv.h?r1=1.7&r2=1.8 I have no idea why Joe's patch was using an

Re: huge memory leak in 2.0.x

Bill Stoddard wrote: @@ -1340,7 +1343,7 @@ /* Run cleanups */ run_cleanups(&pool->cleanups); -pool->cleanups = NULL; +pool->free_cleanups = pool->cleanups = NULL; /* If new child pools showed up, this is a reason to raise a flag */ if (pool-&g

Re: huge memory leak in 2.0.x

@@ -1340,7 +1343,7 @@ /* Run cleanups */ run_cleanups(&pool->cleanups); -pool->cleanups = NULL; +pool->free_cleanups = pool->cleanups = NULL; /* If new child pools showed up, this is a reason to raise a flag */ if (pool->child) @@ -1886,7 +1889,13 @@ #endif /* APR_

Re: [PATCH]Win32 fix for corrupted byterange reply

Read the comment above. APR_XTHREAD can apply any time we need to share the same file across multiple threads. DuplicateHandle(), for an overlapped open, actually points at the same file. The only risk here is that if you make this change, you must also create a new, unique pOverlapped structure

[PATCH] Win32 fix for corrupted byterange reply

Failure scenario: default_handler opens a pdf file to be sent via apr_sendfile (in other words, the file is opened for overlapped i/o aka APR_XTHREAD). An output filter is loaded (SSL in this case) that prevents apr_sendfile() from being used so we need to call apr_file_read() to read the file c

[PATCH]Win32 fix for corrupted byterange reply

Failure scenario: default_handler opens a pdf file to be sent via apr_sendfile (in other words, the file is opened for overlapped i/o aka APR_XTHREAD). An output filter is loaded (SSL in this case) that prevents apr_sendfile() from being used so we need to call apr_file_read() to read the file c

Re: apr_password_validate on win32 silently mishandles crypted hashes

William A. Rowe, Jr. wrote: At 09:05 PM 5/26/2004, Stas Bekman wrote: I've posted the following wording: /** * Validate hashes created by APR-supported algorithms: md5 and base64. * hashes created by crypt are supported only on platforms that provide * crypt(3), so don't rely on that function unle

Re: Performance of TransmitFile on Windows Servers with 2.0.49

Bill Stoddard wrote: Philip Gladstone wrote: I noticed that the performance of TransmitFile (used when EnableSendFile On on Windows platforms) was significantly worse than EnableSendFile Off. It turns out that the way that TransmitFile is called is *without* the TF_WRITE_BEHIND flag. This means

Re: RESEND: PATCH: Update requested events for a descriptor that is already in a poll set

Robert Norris wrote: Robert, Thanks for resending... No promises but I'll try to review this this week. Please, someone beat me to it. Bill [ I'm resending this, because I didn't get any responses to it the first time. ] Attached is a patch that adds a function apr_pollset_update(). This updates t

Re: I'm back :-)

[EMAIL PROTECTED] wrote: I've been lurking for the last few days, and this list is too quiet. :-) I'd like to stir up trouble again, so I am officially asking to have my commit access re-instated. I am in the middle of creating a new project that uses APR, and I would like to fix the bugs that

Re: RESEND: Deficiencies in the poll and/or socket APIs

Robert Norris wrote: [ Resending, as there's been no discussion, and I'm afraid it may have been missed. I need an answer soon. Thanks :) ] Greg Ames and I are working on an Apache 2.0 patch to do keep-alive reads in an event-loop (to free up threads blocked on keep-alive connections). I expect we

Re: apr/apr-util python dependence

Roy T. Fielding wrote: However I completely disagree that Python (or Perl or PHP) is a good choice for use in build systems. As part of the configure process, I would agree with you, but as part of buildconf, I disagree--not everyone needs to run buildconf--only developers, and if you're a

Re: [Fwd: 2 questions about apr_poll]

Marco Spinetti wrote: Can anyone give me a response? Any kind of response. Please help me. Thanks, regards --Marco I don't think anyone has actually tried to use the pollset API to implement anything useful (I'd be happy to hear othereise). I know a few of us are interested in doing some event dri

Re: routines for fetching load average?

Ben Laurie wrote: Bill Stoddard wrote: Rodent of Unusual Size wrote: Rodent of Unusual Size wrote: would anyone have any thoughts about the idea of adding an api to obtain the system load average? i ask because i need it for an httpd module i'm writing, and i've now got code for linu

Re: routines for fetching load average?

Rodent of Unusual Size wrote: Rodent of Unusual Size wrote: would anyone have any thoughts about the idea of adding an api to obtain the system load average? i ask because i need it for an httpd module i'm writing, and i've now got code for linux, freebsd, os x, sunos, and t64u.. no thoughts, uh

Re: Apr_poll

Marco Spinetti wrote: Hi all, because of my failure using threads in apache 1.3.x with apr (apache mail list tells me that using threads with apache 1.3 isn't possible), I decided to replace threads with apr_poll. I don't know much about apr_poll: my purpose was to use threads to execute differ

Re: what about 2.1.0 ?????

William A. Rowe, Jr. wrote: What ship? Did 2.1.0 actually go anywhere? Seems from the folks complaining that they didn't feel we ever released it. Proof is in the pudding - are we at 2.1.1-dev? Bill Actually, the proof of the pudding is in the eating :-/ Bill

Re: Proposed PRNG patch

Ben Laurie wrote: Bill Stoddard wrote: Does Aaron Gifford have the rights to all the code submitted under his copyright? I have no idea. Feel free to ask. Since you are an APR PMC member and are about to commit the code to an APR repository, isn't the task of vetting the code your responsib

Re: Proposed PRNG patch

Does Aaron Gifford have the rights to all the code submitted under his copyright? Bill

Re: New APR Website

Justin Erenkrantz wrote: I've redone the APR website in the style of httpd.apache.org: Comments and feedback appreciated, especially in the style of commits to the apr-site repository. ;-) If someone wants to submit a new logo for APR, it'd be much appreciated too! Enj

Re: [patch] sendfile on win32 slow (bug #20382)

Maarten Bekers wrote: To prevent an DoS, perhaps WaitForSingleObject() could be called in a loop with, check the value of GetOverLappedResult() for a 'sane' value (this can be the old MAX_SEGMENT_SIZE), and if the amount of bytes transmitted since the last call to GetOverlappedResult() is smaller

Re: [patch] sendfile on win32 slow (bug #20382)

> To prevent an DoS, perhaps WaitForSingleObject() could be called in a loop with, check the value of GetOverLappedResult() for a 'sane' value (this can be the old MAX_SEGMENT_SIZE), and if the amount of bytes transmitted since the last call to GetOverlappedResult() is smaller than MAX_SEGMENT_SIZ

Re: [patch] sendfile on win32 slow (bug #20382)

Maarten Bekers wrote: hi, Maarten, How do you propose to handle Timeout processing with your patch? Please correct me if i'm wrong, but to my understanding, the TransmitFile() call is run in overlapped mode, hence transmitfile() returns almost immediatly and only blocks on the WaitForSingleObject

Re: [patch] sendfile on win32 slow (bug #20382)

Maarten Bekers wrote: Hi, End of May 2003, i submitted bug 20382 (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20382) which describes an issue with Apache on Windows2000 Advanced Server performing very poorly in some tested configurations. I also attached a proposed patch (which i'm sure can b

Re: cvs commit: apr/locks/unix proc_mutex.c

[EMAIL PROTECTED] wrote: wrowe 2003/08/06 16:54:31 Modified:locks/unix proc_mutex.c Log: Introduce the proc_mutex_no_tryacquire stub, returning APR_ENOTIMPL, for all unimplemented trylock vectors. Prevents us from simply segfaulting when a given proc_mutex style does not

Re: Creating an allocator with no mutex...

Great catch guys. This probably saved Jeff, Greg and I some major league headaches in the future :-) Bill Brad Nicholes wrote: I think we just discovered what the real source of the problem is. It appears that apr_pool_create_ex() is trying to extract the mutex from the wrong allocator when an a

Re: remaining issues prior to 1.0?

Justin Erenkrantz wrote: --On Wednesday, June 25, 2003 1:29 AM -0400 Cliff Woolley <[EMAIL PROTECTED]> 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

Re: remaining issues prior to 1.0?

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 <[EMAIL PROTECTED]> 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

Re: submission of new Windows rwlock code

Marc M. Adkins wrote: I've re-coded the Windows rwlock based on the OS/2 algorithm implemented by Brian Havard. My test program doesn't show starvation with this algorithm. I'm assuming that the code is stable and works correctly on OS/2, and it's essentially the same code here, plus it passes all

Re: call for vote Re: [PATCH] Re: Frankentables

Brian Pane wrote: Thanks. IMHO, a 4x increase in CPU usage for the worst case isn't a problem, as that's a 4x increase in an operation that's only a few percent of the total cycles anyway. But since the 4x degradation in the worst case may be controversial, I'd like to have a vote first. I'm +1 f

Re: PRNG

Ben Laurie wrote: It has been suggested that I should make my new PRNG (as yet unwritten) a part of APR, since the original motivation was to fix the UUID problems in APR. I'm more than happy to do that, it seems like the best way to get the cross-platform support it needs, and it does mean there's

Re: Win32 apr_sockets; Random notes from the 'oh, duh' department

William A. Rowe, Jr. wrote: At 01:15 PM 4/24/2003, Bill Stoddard wrote: That should not be the case. Last time I checked, I though we set the timeout then sent 64K (?) chunks then reset the timeout for the next 64k chunk. This is -eaxactly- what 1.3 does on Unix (where signals are used as the

Re: Win32 apr_sockets; Random notes from the 'oh, duh' department

That should not be the case. Last time I checked, I though we set the timeout then sent 64K (?) chunks then reset the timeout for the next 64k chunk. This is -eaxactly- what 1.3 does on Unix (where signals are used as the timeout mechanism). This has someone changed that w/o my noticing? I'll

Re: Win32 apr_sockets; Random notes from the 'oh, duh' department

This is horribly inefficient on Windows where sys call overhead is high. Windows uses the builtin setsockopt(SO_RCVTIMEOUT) timeout mechanisms (which are part of the BSD socket spec but is not implemented on Unix). If, as you are reporting, WSA* calls are not really working as they should, t

Re: Win32 apr_sockets; Random notes from the 'oh, duh' department

William A. Rowe, Jr. wrote: Folks, we have a number of real issues with the win32 implementation of sockets which I think I can fix over the next day or so, but I'm just dropping off this note early enough for folks to bitch^H^H^H^H^H comment. Serious Problem #1: Blocking Socket, apr_sendv()

Re: windows nagle settings

+1 Allan Edwards wrote: Anyone know why APR_TCP_NODELAY_INHERITED is not defined in apr.hw? Or why ap_sock_disable_nagle is not defined for Windows (looks like this was omitted unintentionally). Windows is exhibiting predicatable performance problems because nagle is enabled. The following patch fi

Re: [PATCH] letting the app do something useful when apr_proc_create() fails in the child process

+1, this looks like very useful function. I would like to see a bit more explanation in the child_errfn_set making it clear that this function is used to accurately report failures in the 'exec' of a 'fork & exec'. Also explicitly state that this function can only be used on systems that use f

Re: apr_socket_accept() interrupted on Win32 corrupts master socket?

William A. Rowe, Jr. wrote: Vaclav, yes- this is a 'windoze thingy' :-) Hummm perhaps... However, if the listener is really whacked after the timeout, then I would think the problem is in either apr_socket_accept for windows or more likely a bug in the application. Bill

Re: Altogether Broken OtherChild logic

So I 've actually spent some time looking at this... apr_proc_other_child_check() on Unix came first, afaict. Right you are. Now we're left with ery simple problem. OC works on Unix today, and it's broken on Win32. Unix's logic is well exercised by a larger group, WinNT's by a much smaller minor

Re: Altogether Broken OtherChild logic

I am guessing that the windows MPM is whacking the piped logger because ocr->proc->hproc is somehow hosed. No, that is working fine. It is whacking it because I modified the code in _check() to do exactly the same thing on Win32 as it does on Unix. Humm... perhaps you got the cart b

Re: Altogether Broken OtherChild logic

William A. Rowe, Jr. wrote: At 02:03 PM 1/30/2003, Jeff Trawick wrote: wrowe wrote: Finally, it looks like apr_proc_other_child_read is the function we *really* wanted to use within the health check. But it seems all of these apr_proc_other_child functions are really misdocumented within A

Re: Altogether Broken OtherChild logic

William A. Rowe, Jr. wrote: I belive I've deciphered the "RotateLogs doesn't work for access logs on Windows" Apache 2.0.44 bug. It's actually many bugs in conformance. First, rbb's reorg of the WinNT pipe logic (apr/file_io/win32/pipe.c rev 1.46) causes server/log.c ap_open_piped_log() to create

Re: Altogether Broken OtherChild logic

William A. Rowe, Jr. wrote: I belive I've deciphered the "RotateLogs doesn't work for access logs on Windows" Apache 2.0.44 bug. It's actually many bugs in conformance. First, rbb's reorg of the WinNT pipe logic (apr/file_io/win32/pipe.c rev 1.46) causes server/log.c ap_open_piped_log() to create

RE: Showstopper ... was: Tagged the tree

> IMHO, the proper thing to do is to branch off APR from where 2.0.43 > went off, call that API 1.0. Apply relevant fixes as needed (bumping > versions based on the version rules - i.e. filepath_encoding bumps > the minor). Then, start on APR 2.0 with removal of deprecated > functions and we

[PATCH] Update to Brian's patch to allocate brigades out of the bucket allocator

If a pool is passed to apr_brigade_create, the brigade is allocated out of the pool. If the pool is NULL, the brigade is allocated out of the bucket allocator. We don't want a pool pointer hanging around in a brigade allocated out of the bucket allocator. That's just asking for trouble. This patch

RE: Tests hanging on Windows

> On Wed, 11 Dec 2002 [EMAIL PROTECTED] wrote: > > > > > The tests currently hang in testpipe on Windows. The problem is the test > > that tries to read from the pipe with a timeout. The test doesn't write > > anything to the pipe before reading, although it does set a 1 second > > timeout. Howe

RE: [PATCH] Fix Win32 build

Committed. Thanks for the patch. Bill > > The following patch fugbixes two typos: > > Index: network_io/win32/sendrecv.c > === > RCS file: /home/cvspublic/apr/network_io/win32/sendrecv.c,v > retrieving revision 1.60 > diff -u -u

RE: [PATCH] Fix for bug #7617: race condition causes 3 second CGI delay

Kai, Thanks for the patch. I will be committing it later this evening. For future reference APR patches to APR should be posted to [EMAIL PROTECTED] Thanks again. Bill > > When running my newly installed apache 2.0.40 on my RedHat > 8.0 linux box, I noticed some strange 3-second delays > for c

RE: apr_xlate not thread safe

> > >> > > >> Better that we document which returned apr_foo_t's are threadsafe, > > >> which ones are not, > > > > > > Yep. > > > > Nah. Subversion was doing something incredibly stupid. We were > > walking up the pools until it found the global_pool and then created > > the apr_xlate_t in th

RE: apr_xlate not thread safe

> > At 08:33 AM 11/8/2002, you wrote: > > >> --On Friday, November 8, 2002 4:46 AM +0100 Sander Striker > >> <[EMAIL PROTECTED]> wrote: > >> > >> > Bringing this up here for obvious reasons... > >> > > >> > http://subversion.tigris.org/issues/show_bug.cgi?id=974 > >> > > >> > "Attempting to us

RE: apr_xlate not thread safe

> --On Friday, November 8, 2002 4:46 AM +0100 Sander Striker > <[EMAIL PROTECTED]> wrote: > > > Bringing this up here for obvious reasons... > > > > http://subversion.tigris.org/issues/show_bug.cgi?id=974 > > > > "Attempting to use mod_dav_svn with Apache's worker MPM has revealed > > that the

RE: mission statement? (sander made me do it..)

> On Wed, 30 Oct 2002, Cliff Woolley wrote: > > > On Tue, 29 Oct 2002, William A. Rowe, Jr. wrote: > > > > > >"The mission of the APR project is to create and maintain software > > > >libraries that provide a predictable and consistent interface to > > > >underlying platform-specific im

RE: Renames Pending.

The APR API sounds like is was created by Yoda; every command ends in a verb. "Fooled you I did, hummm?" :-) > At 06:19 AM 10/30/2002, Thom May wrote: > >Ok, here goes (this is much more practical than the patch): > > Agreed. However, I have some mixed feedback here. The long > and short of it;

[PATCH] C_LOCALE and apr_is* functions

On some platforms, apr_isalpha(), apr_isspace(), apr_is* are expensive. On AIX, each call to apr_isspace() calls an internal AIX function named __is_wctype_std(). The "wctype" implies (I believe) "wide character". This is some sort of check to determine the charset of the string being scanned. This

RE: cvs commit: apr/file_io/win32 readwrite.c

> On Tue, Oct 29, 2002 at 12:15:19PM -, [EMAIL PROTECTED] wrote: > > stoddard2002/10/29 04:15:19 > > > > Modified:file_io/win32 readwrite.c > > Log: > > Comment a not so obvious tidbit. > > > > Revision ChangesPath > > 1.72 +5 -0 apr/file_io/win32/readwrite.c >

RE: cvs commit: apr/file_io/win32 filedup.c open.c readwrite.c

>> >The reason for locking the file is to mutex the file pointer. A file > opened for > >overlapped i/o does not have a file pointer. > >I'm not aware of any restrictions but I've not tested this patch and > I think the > >results will be less than predictable. For instance, we lock the file, ca

RE: cvs commit: apr/file_io/win32 filedup.c open.c readwrite.c

> At 06:00 AM 10/29/2002, Bill Stoddard wrote: > > >> And it has a flaw if we are logging errors from the parent, the old > >> race condition still remains. It gets much worse if we factor in > >> the possibility of two child worker processes accessing the fil

RE: cvs commit: apr/file_io/win32 filedup.c open.c readwrite.c

> After a bit of cleanup (thank you for choosing apr_file_seek, it made > the append + xthread solution simple)... this patch should 'work'. > > But the patch has the side effect of being incompatible with other > applications attempting to append to the file [such as piped output > or whatnot.] >

RE: [PATCH] Support APR_APPEND (O_APPEND) with apr_file_write on Windows

> At 12:52 PM 10/25/2002, Bill Stoddard wrote: > >The point of my comment was that this is irrelevant for what I > am interested > >in talking about. > > > >But since we are on the topic... APR_XTHREAD implies the file needs to be > >opened for overlapped i

RE: [PATCH] Support APR_APPEND (O_APPEND) with apr_file_write on Windows

> > You can't flock SHARED... that denies everyone (including yourself) > write access to the file. Please review the FileLockEx docs. > I did. APR_FLOCK_EXCLUSIVE maps to LOCKFILE_EXCLUSIVE_LOCK which locks out all reads and writes. APR_FLOCK_SHARED is what you are calling APR_FLOCK_WRITE (whic

RE: [PATCH] Support APR_APPEND (O_APPEND) with apr_file_write on Windows

> > > At 09:27 AM 10/25/2002, Bill Stoddard wrote: > > > >The only problem with this patch [...] > > > > > > > >--- readwrite.c 19 Sep 2002 12:20:20 - 1.1.1.1 > > > >+++ readwrite.c 25 Oct 2002 13:44:53 - &

RE: [PATCH] Support APR_APPEND (O_APPEND) with apr_file_write on Windows

> At 09:27 AM 10/25/2002, Bill Stoddard wrote: > >The only problem with this patch [...] > > > >--- readwrite.c 19 Sep 2002 12:20:20 - 1.1.1.1 > >+++ readwrite.c 25 Oct 2002 13:44:53 - > >-if (thefile->pOverlapped && !thefile-&

RE: [PATCH] Support APR_APPEND (O_APPEND) with apr_file_write on Windows

Speculation... moving the file pointer (with SetFilePointer()) is a "bad thing" when done inside a locked region. Bill > > The only problem with this patch is that it occasionally causes the > WriteFile to block indefinitely and all the other worker threads block on > apr_file_lock waiting for th

[PATCH] Support APR_APPEND (O_APPEND) with apr_file_write on Windows

The only problem with this patch is that it occasionally causes the WriteFile to block indefinitely and all the other worker threads block on apr_file_lock waiting for the file lock. I can send several thousand requests through the server before it hangs. I don't see anything obviously wrong her

RE: Compiling the APR testsuite on Windows

> On Tue, 22 Oct 2002, Bill Stoddard wrote: > > > Q for Bill Rowe... > > I see a bunch of win32 stuff in apr/test but it is not at all > clear where to > > start. > > I would suggest throwing it out and starting over. This is not a > complaint on the curr

Compiling the APR testsuite on Windows

Q for Bill Rowe... I see a bunch of win32 stuff in apr/test but it is not at all clear where to start. Bill

RE: cvs commit: apr/memory/unix apr_pools.c

> > On Tue, Oct 22, 2002 at 01:49:03AM -0400, Ryan Bloom wrote: > > Because there is a difference between unset and NULL value. One of them > > was specifically set by the program, the other is a programmer trying to > > query for a value that was never set. They are two different > cases. This

[PATCH] Win32 apr_shutdown

Allan Edwards ran across this one while debugging a problem with 2.0 closing sockets early. I'm pretty sure this was a quick and dirty way to detect whether APR was being compiled for WINCE or not and the check was incorrect (SD_RECEIVE is #defined to 0 on NT/2000). Any comments before I commit th

[PATCH] Win32: Why explicitly futz with the file pointer?

Why do we need to call SetFilePointer to each call of apr_file_write()? In the common case where only threads in a single process write to a file, calling SetFilePointer is a waste of cycles. If threads from multiple processes are writing to a file, then we are broken unless the application explici

RE: building Release symbols for Win32

> > Unless someone knows a trick that I'm not aware of > debugging Win32 crash dumps (DrWatson .dmp files) can > be a real pain unless you have symbols because > Frame Pointer Omission records make it hard to > construct the call stack from a dump. Having symbols > that match the binary build hand

RE: Patch for unix/poll.c (!HAVE_POLL)

I cannot understand your patch. Please submit as a unified diff and make sure you are using the most recent version of APR. Thanks, Bill > > On Win2K, I was having a consistent problem with ab in the last N > iterations with concurrency N. For example, running "ab -n 20 -c 10 > http://example.c

RE: Patch for unix/poll.c (!HAVE_POLL)

I am reviewing this. BTW, unified diffs are considerably easier to read (cvs diff -u or diff -u) Thanks, Bill > -Original Message- > From: Charles Reitzel [mailto:[EMAIL PROTECTED] > Sent: Thursday, September 26, 2002 1:30 PM > To: dev@apr.apache.org > Subject: Patch for unix/poll.c (!HAV

RE: [PATCH} cut and pasto in apr_poll.h

I just committed the patch. Thanks, Bill > > Garrett Rooney wrote: > > This patch corrects what looks like a cut and past error in the comment > > describing apr_pollset_destroy. > > has anyone had a chance to take a look at this? it's a really simple > change, just some comments that were cut an

  1   2   3   >