[Web-SIG] buffer used by socket, should also work with python stdlib Re: Request for Comments on upcoming WSGI Changes

René Dudfield renesd at gmail.com
Mon Sep 21 14:58:14 CEST 2009


On Mon, Sep 21, 2009 at 1:27 PM, Armin Ronacher
<armin.ronacher at active-4.com> wrote:
> Hi,
>
> René Dudfield wrote:
>> That's all the arguing and explaining I'll do on this - I'm not going
>> to rewrite cherrypy for you as proof.
> If it just puts a burden on implementors on the client and server side
> and there is no proof for it to be faster for real world applications we
> can probably just ignore that then.
>
>
> Regards,
> Armin
>

hi,

yes I think ignoring it for now is a good idea.


However, it could be a good addition to a future spec.

Currently wsgi forces anything built on top to be able to not use them.

It's zero extra work for implementors who don't want to specify a
buffer.  Implementors and clients can just not pass in or use a
destination buffer.

# non caring use:
buf = recv(socket, nbytes)

# buffer caring use:
buffer = pool.get_buffer()
buf = recv(socket, nbytes, buffer)

So I don't see it as a burden to use for people who don't care about it.


To explain the mmap use case more clearly... you could pass in a
memory mapped buffer to allow the process to write to disk directly...
or as shared memory so other processes can mmap the data and process
it.  Rather than sending your data over a pipe(as in fastcgi), you can
just access it directly.

As another piece of evidence that it is faster to use buffers, rather
than allocate all the time, nginx uses memory pools.  So does
apache... and lighttpd...


More information about the Web-SIG mailing list