httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dean gaudet <>
Subject Re: Extraneous socket read?
Date Tue, 03 Jul 2001 04:44:42 GMT
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!)


View raw message