[Web-SIG] [RFC] x-wsgiorg.suspend extension

[Graham Dumpleton]

On 12 April 2010 06:07, Manlio Perillo <manlio_perillo at libero.it> wrote:
> I'm not sure about the correct procedure to follow, I hope it is not a
> problem.
>
> I here propose the x-wsgiorg.suspend to be accepted as official WSGI
> extension, using the wsgiorg namespace.
>
> The extension is documented in doc/wsgiorg.suspend.rst document in the
> txwsgi source distribution, available on:
> http://bitbucket.org/mperillo/txwsgi/
>
> The direct link to the specification is:
> http://bitbucket.org/mperillo/txwsgi/src/tip/doc/wsgiorg.suspend.rst
>
> The extension is implemented in txwsgi implementation for Twisted Web
> server, and I'm going to implement it in the ngx_http_wsgi_module
> implementation for Nginx server.
>
> The extension is very easy to implement.
> It also generalize the proposed x-wsgiorg.fdevent extension.
>
> Please, see
> http://bitbucket.org/mperillo/txwsgi/src/tip/doc/examples/demo_fdevent.py
> for a comparison of the same example described in fdevent specification,
> implemented using suspend and Twisted reactor API.
>
>
> Thanks to Christopher Stawarz for writing the fdevent specification,
> since I was able to use it as a reference.
>
>
> Some additional notes.
> x-wsgiorg.suspend extension can be implemented in both WSGI 1.0 and the
> proposed WSGI 2.0.  However, due to the lack of start_response support,
> the usability is limited.

In the code of demo_fdevent.py it has:

    while True:
        while True:
            ret, num_handles = m.perform()
            if ret != pycurl.E_CALL_MULTI_PERFORM:
                break
        if not num_handles:
            break

        read, write, exc = m.fdset()
        resume = environ['x-wsgiorg.suspend'](1000)
        if read:
            readable(read[0], resume)
            yield ''
        else:
            writeable(write[0], resume)
            yield ''

The registration of file descriptors doesn't occur until after the
first suspend() call.

If the underlying reactor that the WSGI server is presumably also
using doesn't know about the file descriptors at that point, then how
does it now to return from the suspend().

You are also calling perform() before that point. When calling that,
it is presumed you have already done a select/poll to know data is
available, but you haven't done that on first pass through the loop.
If you call that and data isn't ready, can't it block still.

This example also illustrates well why I am so against an asynchronous
WSGI server extension.

The reason is that your specific application has to be with this
extension bound to the specific event loop mechanism used by the
underlying WSGI server.

I can't for example take this application and host it on a different
WSGI server which implements the same WSGI extension but uses a
different event loop.

If one can't do that and it is tied to the event loop and
infrastructure of the underlying WSGI server, what is the point of
defining and implementing the WSGI extension as it doesn't aid
portability at all, so what service is it actually providing?

In that respect, the extension:

http://www.wsgi.org/wsgi/Specifications/fdevent/

provided more as at least it tried to abstract out a generic interface
for registering interest in file descriptor activity and so perhaps
allow the application not to be dependent on the specific event loop
used by the underlying WSGI server.

>From the open issues of that other specification however, you can see
that there can be problems. It only allowed an application to be
interested in a single file descriptor where some packages may need to
express interest in more than one.

Quite often an application is never going to be that simple anyway.
Some event systems allow a lot more than just watching of file
descriptors and timeouts however. You cant come up with a generic
interface for all these as they will not be able to be implemented by
a different event system which isn't so feature rich or which has a
different style of interface. Thus applications are restricted to the
lowest common denominator and likely that is not going to be enough
for most and so have no choice but to bind it to interfaces of
specific event loop. If that is going to be the case anyway, you may
as well forget about WSGI and write to that event systems specific web
server interface.

So, given that one of the strengths of WSGI is that it is an interface
which aids portability of applications to different hosting
mechanisms, explain to me what purpose this WSGI extension has if it
doesn't aid portability given that your application still has to be
aware of the underlying event loop of that specific system anyway.

Graham