Простой пример некой функции обработчика:
1. fread(..)
2. <do math>
3. fwrite(...)
В 1 и 3 происходит блокировка процесса. Процесс пока не дождется ответа от файловой системы, не сможет обработать новый запрос. Асинхронное api? Да, это улучшает отзывчивость, но стоить опуститься на уровень ниже и мы увидим там ioctl. Так как ioctl по своей сути обязан возвращать результат, реализация его в принципе невозможна в асинхронном режиме - вызывающий поток будет блокироаться.
Вся проблема крайне глубока и начинается с реализации железа еще с 60х годов прошлого века. Первоначальная архитектура в принципе не предполагала более чем одного потока исполнения, поэтому - вызвал функцию, подождал, обработал. Потом вкостылили прерывания. Глобально за все это время ничего не изменилось.
Потом появился си, кресты, явы хаскели эрланги. Но суть не изменилось, все наследовало концепцию предыдущего: вызвал, подождал, обработал.
Какой же выход?
Идеальный язык программирования в моем понимании в идеальной системе вообще не имеет блокирующих выходов. Там нет функций, нет точек входа, нет точек выхода и возврата значения. Величайшее зло кроется именно в этом.
Я вижу реализацию фукнций, как бесконечный цикл вида: get_message() -> <process_message>->get_message(). <process_message> может породить одно или несколько событий, может произвести обработку данных, может отправить сообщение. Может здесь ключевое слово. Весь рабочий цикл программы и ее подпрограмм - это переход из одного состояния в другое.
Да, теория автоматов. К сожалению, мне не хватает достаточных математических знаний, чтобы описать идею более подробно.
Рабочий цикл каждой подпрограммы может достигать тысяч и десятков тысяч правил перехода. Ни один человек не в состоянии это хранить в уме, а тем более закодить на существующих языках программирования. Так что все это чистой воды теория.
Но я видел практический выхлоп зачаточной реализации этой концепции в виде сгенерированных исходников на си с готовой машиной состояний для реалтаймовых систем. Поэтому утверждаю, что эта концепция реальна. Мало того, мы рано или поздно к этому прийдем как к основной концепции построения программ - рост числа многопоточных процессов и количества ядер не остановить.
