I had the same thought about third party workers. I just fail to see how a
false positive wsgi.multithread could ever be bad. Maybe it would cause
some code to take a slower, safer path, but it shouldn't break anything.

I found it strange that gevent pywsgi and tornado both set it to false
internally. Seems wrong to me. I overrode it for pywsgi in this patch. I
decided that since the asynchrony is a bit more explicit in tornado perhaps
it is not crazy to have it set to False. If I were the maintainers, though,
I would choose True.
On Jun 23, 2013 11:50 PM, "Benoit Chesneau" <notifications@github.com>
wrote:

> In gunicorn/workers/async.py:
>
> > @@ -81,6 +81,7 @@ def handle_request(self, listener, req, sock, addr):
> >              self.cfg.pre_request(self, req)
> >              resp, environ = wsgi.create(req, sock, addr,
> >                      listener.getsockname(), self.cfg)
> > +            environ["wsgi.multithread"] = True
>
> I'm not aware of a public worker based on the async interface, but I
> prefer to be cautious on that one and not change the defaults.
>
> I will see how to handle that in the eventlet worker.
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/benoitc/gunicorn/pull/558/files#r4836867>
> .
>