On Mon, 2 Jul 2001, dean gaudet wrote:
> On Mon, 2 Jul 2001, Brian Pane wrote:
>
> > then it should be possible to eliminate a system call by not doing the
> > initial read before the select.
>
> that sounds correct and a desirable change. i think the current behaviour
> goes all the way back to the first iol stuff i did, and was possibly just
> a thinko?
>
> oh perhaps it was because i didn't want to pay for a stack allocation on
> every entry to the low level send/recv routines? (which is why there's a
> separate wait_for_io_or_timeout routine)
>
> that change is worth benchmarking.
aha, i remember a bit now.
certainly for an HTTP server what you describe is the best in almost
all cases (except receiving a big POST or PUT). but for an HTTP proxy
receiving data, your select-first change would likely add almost a select
per read. similarly for other non-HTTP protocols.
i bet the heuristic is more along the lines of:
if (this is the first read, or the previous read filled
the entire buffer) {
try read() first
}
else {
try select() first
}
but it's such a shame to add a flag to the socket structure and more
conditionals :)
er i guess it doesn't matter, apr_socket_t is already bloated :) (aie!
is get{sock,peer}name really so expensive / used so much that you need to
keep userland copies?? that means you're paying for it twice! once in
the kernel, once in userland!)
-dean
