The CGI can't talk to the socket fd unless it's going to implement
HTTP/1.1. Specifically it has to chunk unless it sends a Content-Length
header. This isn't something that CGIs do... it's not part of the CGI
"spec". The web server has to twiddle the data unfortunately, and apache
tries to do as little as possible, just wraps up the buffers with chunking
headers/trailers and writev()s the sucker. But CGIs are boring, agreed.
(There are also access control concerns on persistent connections... you
just can't give up control of the socket fd on a public server.)
> We have a mechanism for passing the data channel itself. Checksum caching
> is a seperate issue to this.
I'm not sure the data channel is fine grain enough. Consider webmail
again -- when a message is displayed it essentially goes through a filter
that tweaks < > & to their safe representations. Long strings from the
original file are unmodified... it'd be cool if we didn't have to pay an
extra write for all the unmodified bytes.
But yeah, I agree a lot of this is just userland discipline... with the
right minimal set of kernel knobs to twiddle.
I think on the socket receive side this is really interesting -- but I
don't see how you're able to land the packets in the right page/acl
without spending a bunch of extra PCI cycles. Gotta be careful to get the
balance right or you lose all the gains as memory speeds go up. But I'm
not familiar enough with the scatter capabilities of the hardware...
Dean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/