Как встраиваемый язык — Lua для этого и сделан — позволяет легко управлять тяжелой логикой на erlang.
Вообще-то легковестный нити можно положить поверх setTimeout/setInterval/process.nextTick — что даст хорошую совместимость с legacy кодом.
По поводу multi-node IPC Я буду очень рад если Вы сможете показать как сделать легко такую же бесшовную реализацию как и в Erlang (в т.ч. автовыбор порта, сериализация объектов, переподключение, удаленная консоль) — ну и самая вкусная фишка Erlang — это полная связь между IPC и fault-tolerance.
ZMQ — это больше обмен сообщениями, а термин IPC в себя включает НЕ только обмен сообщениями на низком уровне, но и ряд других сервисов.
Тоже самое можно сказать например и про Lua (тоже однопоточная модель) — однако github.com/rvirding/luerl (очень даже хорошее решение)
Есть memcached подобная реализация хранилища для Erlang — вот и хранилище разделяемых данных.
Естественно что не факт — что реализация на Erlang будет самая быстрая — однако как минимум будет иметь 3 основных преимущества которые в других языках или отсутствуют или осложнены — (1) fault-tolerance (2) виртуальная многопоточность (lightweight-threads) (3) multi-node IPC — что для серверных решений самое то.
Вы видно не совсем меня понимаете — не нужно путать язык и реализацию. Node.js — это V8 на стероидах.
С++ реализацию естественно она не обгонит — глупо бы было утверждать обратное — но вот в многопоточных задачах думаю Erlang победит (это уже много раз проверялось), и в каких-то моментах обойдет Java/Rhino — поскольку JVM тяжелее чем BEAM или HiPE.
Erlang хорош — но если проект разрабатывается не одним человеком (как правило так и есть), или будет иметь длинный жизненный цикл, или передан позже на утсорс другому человеку — то выбор тут невелик — или PHP или node.js на другое решение вряд-ли согласиться основной заказчик проекта.
Вообще-то для Erlang это решается транзакционными присваиваниями, по аналогии с теми что используются в базах данных.
Учитывая спецификацию — то смотря какую, если Вы решите повернуть сильно в сторону полиморфизма на ECMAScript Harmony — то возможно, а в остальном — Erlang быстрее чем Java, а для Java есть Rhino который очень даже хорош.
Без модуля cluster добиться какой-либо многопоточности проблематично — хотя конечно можно делать spawn процесса и своими силами — но это костыли скорее.
Хоть мой коммент заминусовали — однако…
Если Вы писали хоть раз на Erlang распределенные приложения — то поймете как там легко решается проблема с блокировками и доступу к памяти.
На счет cluster — это модуль увы достаточно сырой, а его API нестабилен.
На счет производительности Вы лукавите — сравните node.js в пули из cluster на общих сокетах — против Erlang, это и будет ответом.
Вообще-то для JS не актуально — согласно спецификации все должно работать однообразно.
Проблемы с порядком есть только в ASM и C/C++ — где решается автоматически через макросы SHL SHR — вот там как раз и будем мистика :)
Из статьи легко можно понять — что все современные движки JavaScript страдают одним недостатком — они однопоточные. Хотя нет — далеко не все — есть Rhino (по сути JIT транслятор JavaScript в Java)
А вот судьбе node.js не позавидую (сам на нем пишу — поэтому знаю что говорю) — разработчики V8 еще не скоро пофиксят проблемы в x64 и создание/управление Scope
P.S. а сейчас просто жду — может на KickStarter кто-нибудь выдвинет проект по реализации JS движка поверх Erlang — вот тогда будет действительно хорошо — особенно в многопоточности.
О, Боже. Смотрите не поставьте это на РЕАЛЬНЫЙ сервис — если Вы читали README то должны понимать что установка этого пакета необратима + входит в конфликт со стандартным Windows окружением, ну и заодно пути для NTFS станут Case-Sentensive.
дело в том что MS и не планировала делать функционал консоли подобным образом.
Изначально она пошла со времен 3.11, после в 95/98/2000 тоже запускалась по MSDOS принципу.
А вот уже в новых ОС — весь этот фунционал был заменен через Console API.
В Linux есть псевдотерминалы — да и вообще UNIX-way подразумевает «все есть файлы» — поэтому и работа в этом плане проще.
В этом случае Вы 100% сможете перехватить консоль почти любой программы.
Также обернуть вызовы этих функций в буферы :)
И не забывайте что хуки для x86/x64 будут разные — разника в call conversion
Сейчас I2P роутер написан на гибриде из Java и некотором наборе нативный бинарных библиотек под конкретную платформу.
Несмотря на то что Java кроссплатформенна — запустить ее далеко не везде можно просто и быстро + на слабых устройствах — типа роутеров с 400MHz — просто не потянут.
Насколько Я помню модуль ida-x86emu не слишком стабилен чтобы использовать его для отладки реальных приложений (хотя некоторых это не останавливает) www.idabook.com/x86emu/
#define cdecl_hook(name1)\ /*Macro definition*/
void name1##_hook(int a1, ...)\ /*Declare hooker*/
{\
int check_s = 0;\
__asm{mov check_s, esp}\ /*Save esp state*/
int *ptr = &a1;\ /*Get pointer to 1st arg, equialent of va_list*/
debug_msg("Advanced",true,"--%s arg list started--", __FUNCTION__);\ /*debug_msg() - vfprintf wrapper*/
for(int i=0; i*4<name1##_arg_amount; i++)\
{\
debug_msg("Advanced",true," |---Element %d: %d", i, ptr[i]);\
}\ /*Arg list -> file(Advanced.txt)*/
debug_msg("Advanced",true,"--arg list finished--\n");\
__asm{lea ecx, a1}\ /*Move addr of a1 to ecx*/
__asm{mov eax, name1##_arg_amount}\ /*move size of args in stack(can get from IDA, for ex.) to eax*/
__asm{label_loop: }\ /*Start loop*/
__asm{mov ebx, dword ptr[ecx+eax-4]}\ /*Move args from stack to ebx in loop and push ebx*/
__asm{push ebx}\
__asm{sub eax,4}\
__asm{cmp eax,0}\
__asm{jg label_loop}\
__asm{call dword ptr[name1##_Detour]}\ /*Call original function*/
__asm{mov esp, check_s}\ /*Restore stack, same as __asm{add esp, name1##_arg_amount}*/
}\
Зачем было городить такой огород если можно сохранить весь контекст целиком? ASM вставки и С++ код как по мне так ней айс + Вы изменяете регистры — таким образом на fastcall у Вас будет геммор.
1) На данный момент не работает с __stdcall'ом, __thiscall'ом и другими соглашениями о вызовах. Не откажусь от помощи или совета по данному поводу.
Сохраняйте весь контекст + стэк, дальше идет детекция на аргументы в стэке, если не помогло — то только ручками указывать тип функции.
2) Как я уже упоминал, опыта в данном вопросе достаточно мало, так что вполне могут быть косяки, которых я не учел, так что просьба сильно не тролить.
Если любите OllyDbg то можете запилить расширение на эту тему в виде внешнего плагина. (кстати там в примерах есть пример breakpoint менеджера)
3) Не нашел аналогов, однако это не значит, что нету более адекватных способов / нельзя оптимизировать текущий. Замечания по данному поводу также были бы кстати.
Есть например утилита API Logger делающая примерно тоже самое.
Вообще-то легковестный нити можно положить поверх setTimeout/setInterval/process.nextTick — что даст хорошую совместимость с legacy кодом.
По поводу multi-node IPC Я буду очень рад если Вы сможете показать как сделать легко такую же бесшовную реализацию как и в Erlang (в т.ч. автовыбор порта, сериализация объектов, переподключение, удаленная консоль) — ну и самая вкусная фишка Erlang — это полная связь между IPC и fault-tolerance.
ZMQ — это больше обмен сообщениями, а термин IPC в себя включает НЕ только обмен сообщениями на низком уровне, но и ряд других сервисов.
Есть memcached подобная реализация хранилища для Erlang — вот и хранилище разделяемых данных.
Естественно что не факт — что реализация на Erlang будет самая быстрая — однако как минимум будет иметь 3 основных преимущества которые в других языках или отсутствуют или осложнены — (1) fault-tolerance (2) виртуальная многопоточность (lightweight-threads) (3) multi-node IPC — что для серверных решений самое то.
С++ реализацию естественно она не обгонит — глупо бы было утверждать обратное — но вот в многопоточных задачах думаю Erlang победит (это уже много раз проверялось), и в каких-то моментах обойдет Java/Rhino — поскольку JVM тяжелее чем BEAM или HiPE.
Вообще-то для Erlang это решается транзакционными присваиваниями, по аналогии с теми что используются в базах данных.
Учитывая спецификацию — то смотря какую, если Вы решите повернуть сильно в сторону полиморфизма на ECMAScript Harmony — то возможно, а в остальном — Erlang быстрее чем Java, а для Java есть Rhino который очень даже хорош.
Без модуля cluster добиться какой-либо многопоточности проблематично — хотя конечно можно делать spawn процесса и своими силами — но это костыли скорее.
Если Вы писали хоть раз на Erlang распределенные приложения — то поймете как там легко решается проблема с блокировками и доступу к памяти.
На счет cluster — это модуль увы достаточно сырой, а его API нестабилен.
На счет производительности Вы лукавите — сравните node.js в пули из cluster на общих сокетах — против Erlang, это и будет ответом.
Проблемы с порядком есть только в ASM и C/C++ — где решается автоматически через макросы SHL SHR — вот там как раз и будем мистика :)
А вот судьбе node.js не позавидую (сам на нем пишу — поэтому знаю что говорю) — разработчики V8 еще не скоро пофиксят проблемы в x64 и создание/управление Scope
P.S. а сейчас просто жду — может на KickStarter кто-нибудь выдвинет проект по реализации JS движка поверх Erlang — вот тогда будет действительно хорошо — особенно в многопоточности.
Если по CPU и RAM жить еще можно — то вот по диску — это будет эпик фэйл.
Изначально она пошла со времен 3.11, после в 95/98/2000 тоже запускалась по MSDOS принципу.
А вот уже в новых ОС — весь этот фунционал был заменен через Console API.
В Linux есть псевдотерминалы — да и вообще UNIX-way подразумевает «все есть файлы» — поэтому и работа в этом плане проще.
— запускаем процесс через CreateProcess
— получаем HANDLE процесса
— делаем инджект через Detours или другую библиотеку
— Список того что нужно хукать — msdn.microsoft.com/en-us/library/windows/desktop/ms682073%28v=vs.85%29.aspx
В этом случае Вы 100% сможете перехватить консоль почти любой программы.
Также обернуть вызовы этих функций в буферы :)
И не забывайте что хуки для x86/x64 будут разные — разника в call conversion
Несмотря на то что Java кроссплатформенна — запустить ее далеко не везде можно просто и быстро + на слабых устройствах — типа роутеров с 400MHz — просто не потянут.
www.idabook.com/x86emu/
Зачем было городить такой огород если можно сохранить весь контекст целиком? ASM вставки и С++ код как по мне так ней айс + Вы изменяете регистры — таким образом на fastcall у Вас будет геммор.
1) На данный момент не работает с __stdcall'ом, __thiscall'ом и другими соглашениями о вызовах. Не откажусь от помощи или совета по данному поводу.
Сохраняйте весь контекст + стэк, дальше идет детекция на аргументы в стэке, если не помогло — то только ручками указывать тип функции.
2) Как я уже упоминал, опыта в данном вопросе достаточно мало, так что вполне могут быть косяки, которых я не учел, так что просьба сильно не тролить.
Если любите OllyDbg то можете запилить расширение на эту тему в виде внешнего плагина. (кстати там в примерах есть пример breakpoint менеджера)
3) Не нашел аналогов, однако это не значит, что нету более адекватных способов / нельзя оптимизировать текущий. Замечания по данному поводу также были бы кстати.
Есть например утилита API Logger делающая примерно тоже самое.