Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 16 Jun 2000 14:11:08 +0930 (CST)
From:      "Daniel O'Connor" <doconnor@gsoft.com.au>
To:        "Daniel C. Sobral" <dcs@newsguy.com>
Cc:        Alfred Perlstein <alfred@FreeBSD.org>, Nate Williams <nate@yogotech.com>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject:   Re: cvs commit: src/sys/kern uipc_socket.c uipc_socket2.c src/sy
Message-ID:  <XFMail.000616141108.doconnor@gsoft.com.au>
In-Reply-To: <3949AE78.E0BD49F7@newsguy.com>

next in thread | previous in thread | raw e-mail | index | archive | help

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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.000616141108.doconnor>