Вопрос по архитектуре: одопоточность vs треды vs another_stuff

«event-driven» это методология написания кода, которая чуть менее чем никак не относится к его исполнению

Хорошо, щас поправлю. А как правильно называть? Событийно-ориентированная модель?

«event-driven» это методология написания кода, которая чуть менее чем никак не относится к его исполнению
Событи́йно-ориенти́рованное программи́рование (англ. event-driven programming; в дальнейшем СОП) — парадигма программирования, в которой выполнение программы определяется событиями — действиями пользователя (клавиатура, мышь), сообщениями других программ и потоков, событиями операционной системы (например, поступлением сетевого пакета).

Где тут про методологию написания кода независимую от исполнения написано?

выполнение программы

поведение программы

Выполняться оно может хоть на кластере из китайцев так, как им вздумается

Ты пишешь программу и н знаешь, как она себя будет вести?

Семантика поведения программы соответствует семантике языка, на котором она написана, семантика исполнения программы соответствует семантике исполнителя.

Ты хоть сам то понимаешь, что ты говоришь? Исполнитель текста программы - это и есть исполнитель языка. Исполнитель непосредственно программы — условно, разве что процессор. Какая нах семантика? Семантика головного мозга.

Смотри, программа на некотором языке должна быть эквивалентна себе, скомпилированной в язык исполнителя. В том смысле, что при применении к одним и тем же данным, эти программы дадут один и тот же результат. Но это не значит, что каждый элементарный кусок кода на оригинальном языке несет ту же семантическую нагрузку, что и кусок кода на языке исполнителя.

Грубо говоря, ивенты существуют у тебя в голове и в языке, на котором ты пишешь. А реализовано это может быть через треды, через процессы, так, как предлагает ТС, да как угодно, лишь бы внешняя семантика сохранилась. Пусть хоть твоя скомпилированная программа вообще имеет огромную таблицу соответствия: «внешние данные — код, который нужно выполнить/ответ, который нужно вернуть».

Ну, вот допустим, есть 2 языка с разными моделями исполнения: асинхронная однопоточная и многопоточная. Пусть в обоих языках есть инструкция onEvent, и она означает в обоих семантиках то ж самое — повесить на событие действие. В обоих языках мы пишем такие программы: onEvent=longCalculation. Допустим, юзер инициировал этот event. Пошло вычисление. В однопоточной модели, это вычислние заблокирует обращения других пользователей. Это значит, что, допустим, запрос длает Вася, Васин запрос обрабатывается, в это время ломится запрос Пети, который становится в очередь. Дождется ли Петя окончания обработки запроса Пети? Если бы была многопоточность, обработка запроса Пети началась бы моментально. Если, допустим, обработка Васиного запроса занимает час, Петя не будет ждать.

Что мы имеем в сухом остатке? То, что «семантически» эквивалентные в разных языках конструкции «onEvent» приводят к различным рзультатам. И как же, в таком случае можно говорить о «внешняя семантика сохранилась». Никак. Вншняя, как ты говоришь, семантика по-любому зависит от реализации, мы имем 2 разных результата: «Петя получил ответ» и «Петя НЕ получил ответ». Поэтому все высоколобые рассуждния об эквивалентности семантик — есть ни что иное как демагогия. Математические выкладки всегда противоречат реальности, когда вопрос касается времени.

Ну, да, и в догонку, риторичский вопрос, можт ли программист, пишуший на языке с семантикой, где onEven означает просто на такое-то событие повесить такое-то вычислние, абстрагироваться от реализации? Хо-хо.

Петя не будет ждать

Его проблемы, если семантика исходного языка не гарантирует ему фиксированное время выполнение

Собственно вопрос: почему так называемые «архитекторы» не пошли по простому и очевидному пути?

Почему не пошли? Всё это есть. В NEXTSTEP выбрали такой подход, о котором пишешь ты, и реализовали это всё в Objective-C runtime. Можно вызывать методы на других машинах как на своей, удалённо, через сеть. Microsoft тоже разработала RPC, причём несколько разновидностей. Из открытых и современных средств разработки есть Erlang и его VM, которая спроектирована ИМЕННО для такой архитектуры, о которой пишешь ты. А треды или они же потоки, это параллелизация на одной машине, с многоядерной архитектурой, где важны минимальные задержки и быстрое прееключение между потоками, чего не сделаешь так же качественно на нескольких машинах сразу в едином пуле.

что-то вот это не понятно:

если машина занята, она блокирует единственный поток

это почему? есть же шедулер, он не даст всему стать колом.

Такая архитктура, мне кажется, самоочевидна. Это напоминает модель акторов, вроде. Однако, я не вижу, чтобы это активно применялось. Почему?

Еще как применяется в играх и финансовой сфере

падние производительности на больших нагрузках и дедлоки

Если ты про треды, то наоборот, работа с разделяемой памятью - это единственный способ выжать из CPU по-максмуму. Память медленней CPU, нужно всегда об этом помнить. Shared-nothing - это хорошо, но не супер-эффективно для CPU-intensive задач, это скорее для IO-intensive.

это почему? есть же шедулер, он не даст всему стать колом.

Событие будт получено и поставлено в очередь. Но пока текущее и послдующии, стоящие в очерди задания не отработают, обработка события не наступит. Т.е. пользователь щелкнул мышью и ждет пока дойдт очередь для обработки этого щелчка. Я это имел в виду под блокировкой потока. События никуда не денуться, да, они просто ждут.

Топик не читай - сразу отвечай.

Почему?

Тебе стоит помнить что, во-первых, мир не идеален и не всегда близкое к идеальному(мы же помним, что идеального не существует, правда?) будет использоваться шире, чем более далёкое. А во-вторых - то решение, которое может казаться тебе очевидным и хорошим, может казаться другим людям глупым и бессмысленным. И вовсе не факт, что ты более прав, чем они.

Я не очень понимаю в контексте чего ты говиоришь, но в контексте ос потоки имеют квант времени, больше которого они не выполняются. Если ты про ui thread, то не надо его на долго блокировать, что бы очередь рассасывалась в заданных временных рамках, т.е. опять же не вижу проблнемы.