почему нам нужен zone_highmem на x86?

Может ли [BlockingIOError в асинхронном ридере] вообще никогда не происходить, логически? Если это возможно, то при каких обстоятельствах?

blockquote>

Ответ на этот вопрос почти наверняка будет зависеть от системы. Сам Python не дает никаких гарантий по этому вопросу: такие функции, как os.read и socket.recv, просто проверяют значение, возвращаемое базовым системным вызовом, и, если это указывает на ошибку, продолжают преобразовывать системную ошибку в Исключение Python.

Таким образом, вопрос сводится к тому, может ли чтение из сокета потерпеть неудачу с EAGAIN или эквивалентным, если предыдущий опрос / выбор показал, что он был читаем (и эквивалент для записи). Хотя это, безусловно, звучит как ненормальная ситуация, справочная страница select(2) явно предупреждает об этом в BUGS:

В Linux select() может сообщить дескриптор файла сокета как «готовый к чтению», но, тем не менее, последующие блоки чтения. Это может, например, произойти, когда данные поступили, но при проверке они имеют неверную контрольную сумму и отбрасываются. Могут быть другие обстоятельства, при которых файловый дескриптор ложно сообщается как готовый. Поэтому может быть безопаснее использовать O_NONBLOCK на сокетах, которые не должны блокироваться.

blockquote>

В случае неблокирующих сокетов следует читать «тем не менее последующие блоки чтения» как «тем не менее последующее чтение завершается неудачно с EAGAIN», и предупреждение относится к этому вопросу. Эта проблема также не относится к select(); Страница руководства poll(2) также упоминает о ложных пробуждениях в разделе ошибок, обращаясь к руководству select(2) за подробностями.

Другими словами, переносимый код не должен полагаться на чтение из «читаемых» сокетов, которые никогда не поднимаются BlockingIOError. Asyncio не полагается на него: он реагирует на EAGAIN просто , не завершая будущее , и, таким образом, повторно приостанавливает сопрограмму, ожидающую чтения.