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

[brag]

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

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

[sigmaN]

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

Очень жаль, что всё законичлось применением готового Node.js и обработкой пары собитий on, которые как вообще там появляются не ясно и вникать вы видимо не хотите.

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

Я уже говорил о том, что ваша программа(или движок V8 в случае с JS) это для опереционной системы задача(процесс/поток не так уж важно в данном случае). Получает эта задача процессорное время квантами ибо в ОС встроен нормальный планировщик а не SST. Ядру ОС планировщик тоже дает процессорное время. Теми-же квантами. В ядре вертятся сокеты, обработка пакетов сетевухи и т.д. ОК? Это понятно? Далее, используя API ядра(асинхронный ввод/вывод) на уже готовой операционной системе вы по сути просто делегируете генерацию событий связанных с сокетом ядру. Ядро там в нужное место записывает ваши пожелания и выполняет их, когда кванты времени планировщик выдаст. Там всё мясо, там всё веселье то происходит.
Собственно с обсуждения именно этого веселья мы с вами начали. И я уже пытался обратить на это внимание, но вы сказали, что вам это не важно, потом выкатили Node.JS где это действительно не важно. Круто, что я могу сказать) Как жаль, что немного не в тему.
Вы заявили, что в чудо сервере будет один поток и один стек, а на самом деле запустили задачу под нормально ОС, где ядро и планировщик задач раскидал всё за вас и раздал всем события, на которые вы гордо в одном потоке отреагировали. Ну право же, от изначальной темы беседы мы ушли так далеко, как только было возможно.

Вы же понимаете, что итоговый путь от пакета на сетевухе до вашего события On был пройден через несколько стеков и переключений контекстов(полных переключений, не куцых SSTшных).
И я не хочу сказать, что на SST вы в принципе не сделаете такой сервер. Сделаете. Кактусов покушав немного )

В итоге лично я могу сказать только то, что вы меня удивили как этот JS шевелится. Чуваки работающие над движком V8 однозначно знают своё дело!

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

Уже не один человек высказал мнение, что SST это не так круто как вам кажется и имеет кучу ограничений и проблем. Однако вы по прежнему упрямствуете и, как вы сами выразились, вдуваете себе в голову On