![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Node.native
2012-02-10 10:23 amОдин товарищ по имени Daniel Kang решил портировать Node.js на C++11.
https://github.com/d5/node.native
Недавно в языке наконец-то появились относительно нормальные замыкания, и это позволяет дёргать callback-обработчики из асинхронного сетевого кода, а когда те, в свою очередь, вызывают какую-то блокирующую операцию — разрушать стековый контекст вызывающей стороны и вызывать callback "когда будет готово", т.е. в чистом стековом контексте.
Таким образом callback-обработчикам нельзя делать ничего, что может повлечь блокировку потока в ядре ОС — например, под запретом сетевой и файловый ввод-вывод в обход библиотеки Node.native, обращения к отображённой на диск виртуальной памяти, синхронные DNS-запросы и т.п.
Объекты-замыкания, насколько я понимаю, библиотека копирует в кучу, где они и ждут своего срабатывания. Конечно, их перед этим надо "полиморфно обернуть", т.е. преобразовать статический шаблонный полиморфизм времени компиляции в обычный динамический полиморфизм времени выполнения. (Это автоматически делает библиотека.)
Особенности "программирования коллбэками" a-la Node.js имеют своих критиков (настоящим ковбоям не нужны циклы, настоящие ковбои всегда используют рекурсию), но в условиях отсутствия cactus stack в C++ большего достичь, вообще говоря, нельзя. И да, это намного лучше (гибче), чем boost.asio.
Ну и несомненный плюс в том, что Node.js с его GC-глупостями в перспективе больше не нужен. Javascript-мотор V8, открученный от Google Chrome, к которому как-то присобачили libuv и установили на сервер, имеет весьма туманные перспективы. Я имею в виду, если перед инженерами Google встанет вопрос: какое дизайнерское решение принять по той или иной проблеме: такое, чтобы лучше работал Chrome на десктопе или Node.js на сервере — они ни секунды не колеблясь выберут Chrome и сольют Node.js.
А вообще, это первый практический пример, который убедительно доказывает, что C++11 как язык сильнее C++98. "Modern C++ is not a C++ your grandfather used to code".
https://github.com/d5/node.native
Недавно в языке наконец-то появились относительно нормальные замыкания, и это позволяет дёргать callback-обработчики из асинхронного сетевого кода, а когда те, в свою очередь, вызывают какую-то блокирующую операцию — разрушать стековый контекст вызывающей стороны и вызывать callback "когда будет готово", т.е. в чистом стековом контексте.
Таким образом callback-обработчикам нельзя делать ничего, что может повлечь блокировку потока в ядре ОС — например, под запретом сетевой и файловый ввод-вывод в обход библиотеки Node.native, обращения к отображённой на диск виртуальной памяти, синхронные DNS-запросы и т.п.
Объекты-замыкания, насколько я понимаю, библиотека копирует в кучу, где они и ждут своего срабатывания. Конечно, их перед этим надо "полиморфно обернуть", т.е. преобразовать статический шаблонный полиморфизм времени компиляции в обычный динамический полиморфизм времени выполнения. (Это автоматически делает библиотека.)
Особенности "программирования коллбэками" a-la Node.js имеют своих критиков (настоящим ковбоям не нужны циклы, настоящие ковбои всегда используют рекурсию), но в условиях отсутствия cactus stack в C++ большего достичь, вообще говоря, нельзя. И да, это намного лучше (гибче), чем boost.asio.
Ну и несомненный плюс в том, что Node.js с его GC-глупостями в перспективе больше не нужен. Javascript-мотор V8, открученный от Google Chrome, к которому как-то присобачили libuv и установили на сервер, имеет весьма туманные перспективы. Я имею в виду, если перед инженерами Google встанет вопрос: какое дизайнерское решение принять по той или иной проблеме: такое, чтобы лучше работал Chrome на десктопе или Node.js на сервере — они ни секунды не колеблясь выберут Chrome и сольют Node.js.
А вообще, это первый практический пример, который убедительно доказывает, что C++11 как язык сильнее C++98. "Modern C++ is not a C++ your grandfather used to code".
