Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 50348 invoked by uid 500); 6 Aug 2002 15:57:02 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 50231 invoked from network); 6 Aug 2002 15:57:00 -0000 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.2 Beta Date: Tue, 06 Aug 2002 09:56:54 -0600 From: "Brad Nicholes" To: , Subject: Re: [PATCH] win32 sendrecv.c cleanup Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Rating: daedalus.apache.org 1.6.2 500/1000/N After taking a closer look at the code, I think all that really needs to be done is to fall back to a malloc() if _alloca() fails. I don't know the conditions that would cause _alloca() to fail on Win32 but falling back to a malloc() should work for both platforms even though it may never be called on Win32. 4kb should be fine for NetWare as well although we are not currently defining APR_HAS_SENDFILE. The main reason is because we don't have a sendfile() or TransmitFile() equivalent. I will have to look into this to see if there is something else that we can do. All of our threads default to a 64k stack. The only time that we really run into problems is when a function declares large stack variables and then is called recursively. This happened in Apache 1.3 during the parsed HTML processing. I haven't found any cases yet in Apache 2.0. Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com >>> "William A. Rowe, Jr." Tuesday, August 06, 2002 9:24:11 AM >>> Yes, I sometimes forget that, and certainly we can ifdef it. One old question ... did 4kb make sense for the sendfile header/trailers vector? The new question ... is it large enough to concern you, and would it make sense to use another granularity on Netware (1kb, 2kb?) Letting the sendv logic handle the overflow probably makes sense even at some 1kb threshold. Bill ----- Original Message ----- From: "Brad Nicholes" To: ; Sent: Tuesday, August 06, 2002 7:14 AM Subject: Re: [PATCH] win32 sendrecv.c cleanup > Bill, > NetWare takes advantage of the Win32 Network_io code since we are > also on Winsock. Allocating off of the stack may cause a problem for us > since NetWare has a fixed size stack. Can the orginal code be #ifdef'd > for NETWARE? > > Brad > > Brad Nicholes > Senior Software Engineer > Novell, Inc., the leading provider of Net business solutions > http://www.novell.com > > >>> "William A. Rowe, Jr." Tuesday, August 06, > 2002 2:19:32 AM >>> > Folks, > > Please review the attached patch that eliminates the rather nasty > allocations > that can occur in two situations. One is in apr_sendv() when we have > more than > 50 items, now simply allocate the vectors on the stack [very portable > across > win32, from vc5 onwards.] The other simply allocates a static buffer > for > the apr_sendfile headers and trailers vector concatination, and when > we > exceed it, we simply sendv out the header or trailer as appropriate. > > If I hear no objections I'll commit in a day or two. > > Final question. We 'devolve' to 64kb per sendfile. There is a > comment in there > about exceeding the timeout. What on earth does unix do so special > that it isn't > a problem over on that side? A cluestick across my knuckles would be > appreciated > before I even think about attacking that code. > > Bill >