Как вы уже сказали, циклы событий предназначены для работы с медленным вводом-выводом или, в более общем смысле, с операциями, не задействующими ЦП, которые происходят в другом месте, где выполняется код, требующий результатов таких операций.
Но ввод-вывод — это не только сеть и диск! Существует ввод-вывод, который намного медленнее любого устройства: компьютеры взаимодействуют с людьми!
Ввод через графический интерфейс — нажатие кнопок, ввод текста — все это МЕДНО, потому что компьютер ждет ввода пользователя. Вашему коду требуются данные из внешнего источника (внешняя форма процессора, на котором работает код).
События GUI являются основной причиной программирования на основе событий. Подумайте об этом: как бы вы синхронно программировали графический интерфейс? (можно использовать вытеснение операционной системой, как описано ниже) Вы не знаете, когда пользователь нажмет кнопку. Программирование на основе событий — лучший вариант (известный нам) для этой конкретной задачи.
Кроме того, требовалось иметь только один поток, потому что параллельное программирование СЛОЖНО, а Javascript предназначался для «обычных пользователей».
Вот хороший пост в блоге, который я только что нашел:
http://www.lanedo.com/the-main-loop-the-engine-of-a-gui-library/
Общим для современных библиотек GUI является то, что все они воплощают парадигму программирования на основе событий. Эти библиотеки реализуют элементы графического интерфейса, которые выводят вывод на экран компьютера и изменяют состояние в ответ на входящие события. События генерируются из разных источников. Большинство событий обычно генерируются непосредственно на основе пользовательского ввода, например движений мыши и ввода с клавиатуры. Другие события генерируются оконной системой, например, запросы на перерисовку определенной области графического интерфейса, указания на изменение размера окна или уведомления об изменениях в буфере обмена сеанса. Обратите внимание, что некоторые из этих событий генерируются косвенно посредством пользовательского ввода.
Я хотел бы добавить это:
У нас есть два основных варианта решения проблемы, когда ваш код должен ждать внешнего события (т. е. данных, которые не могут быть вычислены в ЦП, на котором работает ваш код, или извлекаются из напрямую подключенной ОЗУ — все, что не позволяет ЦП чтобы продолжить обработку вашего кода):
- События
- Вытеснение "высшей силой", такой как операционная система.
В последнем случае вы можете написать последовательный код, и ОС обнаружит, когда вашему коду потребуются данные, которых еще нет. Это остановит выполнение вашего кода и передаст ЦП другому коду.
В некотором смысле вездесущая парадигма, основанная на событиях, в Javascript — это шаг назад: написание множества обработчиков событий для всего — это большая работа по сравнению с простым написанием того, что вы хотите, в последовательности и предоставлением ОС заботиться об управлении ресурсом «ЦП». .
Я заметил, что мне никогда не хотелось жаловаться, когда мое программирование на основе событий предназначалось для графического интерфейса, но когда мне пришлось делать это для дискового и сетевого ввода-вывода, я понял, сколько усилий потребовалось для обработки всех событий по сравнению с предоставлением ОС обрабатывает это в фоновом режиме.
Моя теория: справляться с людьми (их действиями) в обработчиках событий было естественно, в конце концов, это и было целью программного обеспечения (программного обеспечения с графическим интерфейсом). Но когда мне пришлось делать все вещи, основанные на событиях, для устройств, это казалось неестественным — мне нужно было приспосабливать аппаратное обеспечение к моим программам?
В некотором смысле программирование, основанное на событиях, которое пришло к нам, — это шаг в сторону от прежних мечтаний о «языках 4-го поколения» и назад к более аппаратно-ориентированному программированию — ради эффективности машины, а не эффективности программиста. Требуется ОЧЕНЬ привыкнуть к написанию кода, основанного на событиях. Писать синхронно и позволить ОС позаботиться об управлении ресурсами на самом деле проще — если только вы не настолько привыкли к коду, основанному на событиях, что теперь у вас возникает рефлекторная реакция на что-либо еще.
Но подумайте об этом: в программировании на основе событий мы позволяем физическим деталям, например, где выполняется наш код и откуда он получает данные, определять, как мы пишем код. Вместо того, чтобы концентрироваться на том, чего мы хотим, мы гораздо больше заботимся о том, как мы хотим, чтобы это было сделано. Это большой шаг от абстракции к аппаратному обеспечению.
Сейчас мы медленно разрабатываем и внедряем инструменты, которые помогают нам решить эту проблему, но даже такие вещи, как промисы, по-прежнему требуют от нас мыслить «на основе событий» — мы используем такие конструкции там, где у нас есть события, т. е. мы должны знать о разрывах. Так что я не вижу НАСТОЛЬКО большого выигрыша, потому что нам все равно нужно писать код по-другому, который имеет такие «разрывы» (т.е. оставляет ЦП).
person
Mörre
schedule
11.04.2015
