How to catch “[Errno 32] Broken pipe” in a WSGI ha

WSGI is extremely useful for building highly concurrent HTTP servers to support e.g. long polling, however, typically, the long running HTTP request will at some point be ended by the client side; to clean up any resources and open handles, the WSGI server backend should be notified of any such events, however, it doesn't currently seem to be possible to catch those events in the WSGI handler:

# pseudocode example

def application(env, start_response):
    start_response(...)

    q = Queue()
    ev_handle = register_event_handler(lambda event, arg: q.put((event, arg)))

    # ??? need to call e.g. ev_handle.unregister() when the HTTP request is terminated

    return iter(lambda: render(q.get()), None)

For example, when using gevent.pywsgi, the corresponding exception (error: [Errno 32] Broken pipe) is thrown somewhere inside gevent and never even seems to surface anywhere the handler could potentially see it:

Traceback (most recent call last):
  File "/Users/erik.allik/.virtualenvs/myproj/lib/python2.7/site-packages/gevent/pywsgi.py", line 508, in handle_one_response
    self.run_application()
  File "/Users/erik.allik/.virtualenvs/myproj/lib/python2.7/site-packages/gevent/pywsgi.py", line 495, in run_application
    self.process_result()
  File "/Users/erik.allik/.virtualenvs/myproj/lib/python2.7/site-packages/gevent/pywsgi.py", line 486, in process_result
    self.write(data)
  File "/Users/erik.allik/.virtualenvs/myproj/lib/python2.7/site-packages/gevent/pywsgi.py", line 376, in write
    self._write(data)
  File "/Users/erik.allik/.virtualenvs/myproj/lib/python2.7/site-packages/gevent/pywsgi.py", line 369, in _write
    self._sendall(data)
  File "/Users/erik.allik/.virtualenvs/myproj/lib/python2.7/site-packages/gevent/pywsgi.py", line 355, in _sendall
    self.socket.sendall(data)
  File "/Users/erik.allik/.virtualenvs/myproj/lib/python2.7/site-packages/gevent/socket.py", line 458, in sendall
    data_sent += self.send(_get_memory(data, data_sent), flags)
  File "/Users/erik.allik/.virtualenvs/myproj/lib/python2.7/site-packages/gevent/socket.py", line 435, in send
    return sock.send(data, flags)

Looks like what happens when a request gets terminated is that, in addition to the (seemingly uncatchable) exception traceback, the iterator that was returned from the WSGI handler is .close()-d. It is thus possible to determine when the any workers/resources/handles associated with the response should be closed. This is basically what werkzeug.wsgi.ClosingIterator does:

class ClosingIterator(object):
    def __init__(self, iterable, on_close):
        iterator = iter(iterable)
        self.close = on_close
    def __iter__(self):
        return self
    def __next__(self):
        return self._next()

def application(env, start_response):
    start_response(...)

    q = Queue()
    ev_handle = register_event_handler(lambda event, arg: q.put((event, arg)))

    return ClosingIterator(
        iter(lambda: render(q.get()), None),
        on_close=ev_handle.unregister
    )

This does not however silence the error message/traceback, but this seems tolerable unless somebody can come up with a solution that can fix even that.