On Thu, Aug 31, 2000 at 03:48:16PM -0500, Guido van Rossum wrote: > I wrote: >... > > Solution? Don't use rfile for reading, but go for the socket itself. Or > > revamp the two classes to forget about the socket once the files (wfile and > > rfile) are created. The latter might not be possible, tho. > > I was about to say that you have it backwards, and that you should > only use rfile & wfile, when I realized that CGIHTTPServer.py needs > this! The subprocess needs to be able to read the rest of the socket, > for POST requests. So you're right. Ooh! I hadn't considered that case. Yes: you can't transfer the contents of a FILE's buffer to the CGI, but you can pass a file descriptor (the socket). > Solution? The buffer size should be an instance or class variable. > Then SocketServer can set it to buffered by default, and CGIHTTPServer > can set it to unbuffered. Seems reasonable. > > Dunno why the unbuffered reading would be slow. I'd think it would still > > read large chunks at a time when you request it. > > System call overhead? I had the same complaint about Windows, where > apparently winsock makes you pay more of a performance penalty than > Unix does in the same case. Shouldn't be. There should still be an rfile.read(1000) in that example app (with the big transfers). That read() should be quite fast -- the buffering should have almost no effect. So... what is the underlying problem? [ IOW, there are two issues: the sock vs file thing; and why rfile is so darn slow; I have no insights on the latter. ] Cheers, -g -- Greg Stein, http://www.lyra.org/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4