В принципе, WSGI не является несовместимым с асинхронным проектированием программ; на самом деле, PEP 333 идет довольно далеко, чтобы указать, как серверы, приложения и промежуточное ПО должны вести себя для поддержки такого рода вещей.
В основе этого лежит возврат итератора в контейнер. Каждый раз, когда вызывается асинхронный wsgi app_iter, он проверяет все ожидающие его асинхронные задачи (соединения с базой данных и т. Д.), И если у какой-либо из них есть данные, app_iter возвращает некоторые данные; в противном случае он возвращает пустую строку. Для поддержки этого контейнеру wsgi необходимо отслеживать все запросы в полете и повторять каждый из них по очереди, чтобы получать больше данных, в дополнение к обслуживанию любой другой отложенной работы, за которую он отвечает.
В принципе, очень немногие wsgi-приложения или фреймворки действительно делают это. почти всегда блоки wsgi блокируются по разным причинам; чтение файлов с диска или загрузка данных из базы данных по какой-либо причине вообще (большинство ORM делают эту проблему непростой задачей). Контейнер wsgi Twisted работает в предположении, что, поскольку некоторые приложения wsgi блокируют, что, возможно, любое приложение wsgi может блокировать, и поэтому всегда запускает их в потоке.
Есть две вещи, которые вы можете сделать; либо изучите собственный веб-фреймворк Twisted, который достаточно прочный или подумайте о создании оболочки wsgi для витой вне собственного витого контейнера. Убедиться, что приложение wsgi на самом деле асинхронно, безусловно, является предварительным условием последнего, но сам wsgi довольно прост, тонкая оболочка над http, и поэтому он должен быть достаточно легким.