ML
Ну если он не понимает
он просто придумал себе свою собственную терминологию и требует, чтобы остальные соблюдали её.
Size: a a a
2019 November 09
AP
Очередной булшит, ну понятно
ML
он просто придумал себе свою собственную терминологию и требует, чтобы остальные соблюдали её.
это вообще частая причина таких непониманий. Человек пытается что-то обсудить, а сам даже не допускает мысли, что его терминология иная, чем у собеседников.
ЕГ
никто не баловался с run_erl и to_erl под win?
ML
никто не баловался с run_erl и to_erl под win?
честно говоря, они и под линуксом то постепенно теряют актуальность
ЕГ
надо посмотреть может что то новое появилось, сейчас в проекте run_erl на старте "дочерних" нод
ML
надо посмотреть может что то новое появилось, сейчас в проекте run_erl на старте "дочерних" нод
Systemd :(
ML
Не люблю его, бажный, непродуманный, но его тащат как дефолт везде
ЕГ
Не люблю его, бажный, непродуманный, но его тащат как дефолт везде
это run_erl?
ML
это run_erl?
не, systemd. У run_erl есть проблемы, но он топорный и в целом к нему без претензий.
А у systemd проблемы в дизайне и в реализации
А у systemd проблемы в дизайне и в реализации
СИ
Он так проектировался. И ему это удается
>Он так проектировался. И ему это удается
не в защиту оратора, но erl_crashdump это обыденность
не в защиту оратора, но erl_crashdump это обыденность
c🦊
>Он так проектировался. И ему это удается
не в защиту оратора, но erl_crashdump это обыденность
не в защиту оратора, но erl_crashdump это обыденность
Но все же стоит признать что это случается не столь часто как могло бы 😂
СИ
Но все же стоит признать что это случается не столь часто как могло бы 😂
да. ведь идеология let it crash )
ML
>Он так проектировался. И ему это удается
не в защиту оратора, но erl_crashdump это обыденность
не в защиту оратора, но erl_crashdump это обыденность
erl_crashdump — это как раз именно надежность виртуальной машины. Она не может дальше работать и дампит состояние на уровне эрланга, а не coredump.
СИ
а вот по поводу nif - насколько нормальная практика инициализировать в onload nif локальный статически атом (типа
или такие вещи надо переинициализировать и передевать в priv?
static ERL_NIF_TERM ok = enif_make_atom(...)) и ипользовать его игнорируя unload, reload и тд?или такие вещи надо переинициализировать и передевать в priv?
ML
#define ATOM(name) atm_##nameигнорируй unload, reload и т.п. Атом не связан с env, его можно сравнивать:
#define DECL_ATOM(name) ERL_NIF_TERM atm_##name = 0
#define LOAD_ATOM(name) atm_##name = enif_make_atom(env,#name)
DECL_ATOM(ok);
static int
load(ErlNifEnv* env, void** priv, ERL_NIF_TERM load_info)
{
LOAD_ATOM(ok);
....
...
return ATOM(ok);
if(a == ATOM(ok)) {
...СИ
>Атом не связан с env,
вообще он создается же в контексте env, и срок жизни их совпадает. в доке так написано.
вообще он создается же в контексте env, и срок жизни их совпадает. в доке так написано.
СИ
только не понятно 1) сколлько этот env живет 2) что происходит если библиотека перегружается
СИ
#define ATOM(name) atm_##nameигнорируй unload, reload и т.п. Атом не связан с env, его можно сравнивать:
#define DECL_ATOM(name) ERL_NIF_TERM atm_##name = 0
#define LOAD_ATOM(name) atm_##name = enif_make_atom(env,#name)
DECL_ATOM(ok);
static int
load(ErlNifEnv* env, void** priv, ERL_NIF_TERM load_info)
{
LOAD_ATOM(ok);
....
...
return ATOM(ok);
if(a == ATOM(ok)) {
...ну я примерно так и делаю . есть структура инициализируемая в onload
static {
...
} atoms;
но вот сейчас гоняю unload , upgrade и как-то не понятно пока как оно должно работатьСИ
Callback environment
Passed as the first argument to all the non-NIF callback functions (load, upgrade, unload, dtor, down and stop). Works like a process bound environment but with a temporary pseudo process that "terminates" when the callback has returned. Terms may be created in this environment but they will only be accessible during the callback.