Система, управляемая событиями и SST(super-simple tasker), Выделено из "ООП. Классы и динамические объекты" Опции

[brag]

Недавно я начал пользоваться динамической памятью. Раньше пользовался только статикой, то есть placement new. Со статикой сложно работать с такими шаблонами, как фабрика обьектов, временные задачи итд.
Программирую в основном под cortex-m3/m4
Код реализации аллокатора вышел довольно простым и быстрым, критически секции есть, но очень короткие(там прочитать/записать пару байт).
При чем я не использую этих всяких монстров под названием RTOS, у меня свой простейший асинхронный планировщик задач, занимает строк 300 кода с комментариями(погуглите запрос "super simple tasker", поймете что это).
В купе с динамическим аллокатором, variable element-size queue, новыми фишками C++ (шаблоны, лямбда-функции, auto) получается очень простой, безопасный и мощный фреймворк.
Вспоминаю работу с классическими Thread-ами(с ихними стеками - куча кода было написано для анализа программ на предмет нужного обьема стека, и теперь эта куча кода отправлена на мусорку) со всеми этими тяжеленными мютексами, семафорами, вечными циклами как страшный сон.

Если кому интересно - расскажу и покажу как это все работает.

[sigmaN]

Вы все равно ничего не поняли. Ключевое слово Wait - оно у вас в голове и у меня тоже было, и очень трудно его было оттуда выбросить.

Могу в аналогичном тоне заявить, что наверно вы тоже ничего не поняли и у вас в голове On. Чтобы кто-то вызвал этот On должен быть где-то и Wait и цикл бесконечный.
Например в эмбэддэд с этим проще, потому что этот вэйт реализуется логикой отвечающей за генерацию прерывания по изменению уровня пина(например). И вы потом гордо залетаете в прерывание, оттуда вызываете свой On и радуетесь. Но кто-то до этого аппаратно делал Wait )

Даже в SST таки есть бесконечный цикл, который крутится и вызывает нужные On взависимости от ивэнтов в очереди.
Чем это отличается от WaitForMultipleObjects() для сокетов? Я не знаю. Наверно ни чем)
Но делая этот системный вызов я отдаю ресурсы другим потокам в ОС(ох уж эти потоки опять а!). Хотя таки да, мог бы крутить цикл и проверять сокеты вручную, потом ложить ивэнт в очередь а потом вызывать On И как глубоко бы вы не зкапывали этот цикл или вэйт он всё равно где-то есть.

Если вы в JS подписываетесь на какое-то событие, чтобы движок дёргал ваш On - это всего-лишь означает что нужный Wait и цикл скрыты где-то далеко.
Так что не шибко то разгоняйтесь с перестраиванием мозга на On.

Надеюсь вы таки поняли о чем я говорю ) Потому что хоть вы в это и не верите, а большинство и с принципами работы SST тут разобрались и про On знают не по наслышке тоже давно )

Сервер будет отдавать запрошенный пользователем файл - устроит? Тестить будете?
В математику давайте пока лесть не будем, об этом позже и там тоже все довольно интересно и тоже все отлично ложится на SST-модель. Просто Javascript не предназначен для сложных вычислений, для этого есть другие инструменты, которые свободно работают в паре с JS.

Файл объемом 1Гб, скорость сети каждого клиента ограничиваем шейпером на роутере до....1мегабита ) Ну, чтоб точно заметно было как остальные клиенты сервера курят бамбук )
Не тратьте силы и так всё ясно же. Застрянет ваш сервер на одном клиенте и пока тот файл не скачает - всё это весело встанет колом.

Ааа, нет! Я придумал! В системе появится таймер, он будет генерировать событие onTimer, в этом событии вы будете проходиться по массиву с сокетами и каждому отправлять там по пару байт данных. Обходя сокеты по кругу. А потом скажите ну вот, все качают и никаких вэйтов ))))))))))

[brag]

Могу в аналогичном тоне заявить, что наверно вы тоже ничего не поняли и у вас в голове On.

Это верно. Я выбросил из головы Wait и вдул туда On.

Чтобы кто-то вызвал этот On должен быть где-то и Wait и цикл бесконечный.
Например в эмбэддэд с этим проще, потому что этот вэйт реализуется логикой отвечающей за генерацию прерывания по изменению уровня пина(например). И вы потом гордо залетаете в прерывание, оттуда вызываете свой On и радуетесь. Но кто-то до этого аппаратно делал Wait )
Даже в SST таки есть бесконечный цикл, который крутится и вызывает нужные On взависимости от ивэнтов в очереди.

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

Чем это отличается от WaitForMultipleObjects() для сокетов? Я не знаю. Наверно ни чем)

А тут Вы уже не правы. WaitForMultipleObjects блокирует пользовательский поток. Все, поток мертвый. В то время, как в SST или яваскрипте в принципе нет такой возможности

Но делая этот системный вызов я отдаю ресурсы другим потокам в ОС(ох уж эти потоки опять а!). Хотя таки да, мог бы крутить цикл и проверять сокеты вручную, потом ложить ивэнт в очередь а потом вызывать On И как глубоко бы вы не зкапывали этот цикл или вэйт он всё равно где-то есть.
Если вы в JS подписываетесь на какое-то событие, чтобы движок дёргал ваш On - это всего-лишь означает что нужный Wait и цикл скрыты где-то далеко.
Так что не шибко то разгоняйтесь с перестраиванием мозга на On.

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

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

Для безопасности есть MPU/MMU, если оно действительно нужно - тогда запросто берем и используем.

Файл объемом 1Гб, скорость сети каждого клиента ограничиваем шейпером на роутере до....1мегабита ) Ну, чтоб точно заметно было как остальные клиенты сервера курят бамбук )
Не тратьте силы и так всё ясно же. Застрянет ваш сервер на одном клиенте и пока тот файл не скачает - всё это весело встанет колом.

Идет. Будете тестить? Файлик сами приготовите любой. Только боюсь, в этом случаи мы не SST-модель будем тестить, а Ваш жесткий диск или Ваш порезанный канал. Но как только Вы подсунете нормальный файл на несколько КБ-МБ и сделаете канал, достаточный для закрузки сервака на полную - все станет совсем иначе.
Хотя даже с гиговым файлом/файлами однопоточный javascript покажет выше производительность, чем классический многопоточный C. Проверим?