From owner-cvs-all Thu Jun 15 21:41:52 2000 Delivered-To: cvs-all@freebsd.org Received: from cain.gsoft.com.au (genesi.lnk.telstra.net [139.130.136.161]) by hub.freebsd.org (Postfix) with ESMTP id 71D3537BBF0; Thu, 15 Jun 2000 21:41:34 -0700 (PDT) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (doconnor@cain [203.38.152.97]) by cain.gsoft.com.au (8.8.8/8.8.8) with ESMTP id OAA07844; Fri, 16 Jun 2000 14:11:08 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <3949AE78.E0BD49F7@newsguy.com> Date: Fri, 16 Jun 2000 14:11:08 +0930 (CST) From: "Daniel O'Connor" To: "Daniel C. Sobral" Subject: Re: cvs commit: src/sys/kern uipc_socket.c uipc_socket2.c src/sy Cc: Alfred Perlstein , Nate Williams , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 16-Jun-00 Daniel C. Sobral wrote: > Daniel O'Connor wrote: > > I can see why it isn't terribly 'nice' but if you want to squeeze more > > performance out of your system it IS necessary to do.. > And this is the falacy. If the architecture prevents you from getting > the desired performace the right way, fix the architecture instead of > patching it. Alas, it doesn't. Sendfile() works for applications other > than http and ftp, for instance. That's the right way of doing it. What > was committed, it would seem, doesn't even handle all HTTP headers, and > certainly won't handle _new_ HTTP headers that industry and standard > groups decide to create. That's the wrong way of doing it. So how should the architecture be changed to accomodate this? If the ability is added to upload a 'pattern' to match (obviously simpler than a re :) I think that would be quite nice. > The correct here is find _why_ there is a performance impact if this > delay accept feature is not used, and fix _that_ instead. Well, my naivity abounds, but I would have thought it was because you do an accept() which returns and then immediatly you go back to waiting on select(). > Alternatively, a _flexible_ delay accept feature should have been > introduced, instead of a hard-wired one. True. --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message