Телеграмм чат группы erlangrus страница 2164

2019 November 09

ML

ну я примерно так и делаю . есть структура инициализируемая в onload

static {
  ...
} atoms;

но вот сейчас гоняю unload , upgrade и как-то не понятно пока как оно должно работать

Забей на атомы в unload. Они этим и хороши, что это просто числа

источник

19:01пожаловаться #1

СИ

Сергей Иванов in ErlangRus

Maksim Lapshin

Забей на атомы в unload. Они этим и хороши, что это просто числа

но я эти атомы потом возвращаю в nif, т.е. это получается грязный хак, потому-что по идее оно должно упасть ведь. потому-что env передаваемый в load - временный и не связан с тем, что передается в nif. или я не так понимаю доку?

источник

19:02пожаловаться #2

СИ

Сергей Иванов in ErlangRus

  All contained terms of a list/tuple/map must belong to the same environment as the list/tuple/map itself. Terms can be copied between environments with enif_make_copy.

получается никакого профита, проще создавать термы каждый раз при каждом вызове nif

источник

19:04пожаловаться #3

СИ

Сергей Иванов in ErlangRus

http://erlang.org/pipermail/erlang-questions/2012-May/066485.html

Currently atoms are independent of environment (ErlNifEnv). That is, you 
can cache atoms by storing them in static variables as done in crypto.c.
This is an undocumented feature however.

To compensate for future possible introduction of atom-GC I have thought 
of documenting this feature with some restriction. Something like

"Atoms created in load/upgrade callbacks are static and can be used in 
any environment"

источник

19:06пожаловаться #4

ML

Maksim Lapshin in ErlangRus

Сергей Иванов

но я эти атомы потом возвращаю в nif, т.е. это получается грязный хак, потому-что по идее оно должно упасть ведь. потому-что env передаваемый в load - временный и не связан с тем, что передается в nif. или я не так понимаю доку?

ну это в теории так и так надо для всех аллоцируемых термов кроме атомов

источник

19:09пожаловаться #5

ML

Maksim Lapshin in ErlangRus

атомы можно запомнить

источник

19:09пожаловаться #6

СИ

Сергей Иванов in ErlangRus

Maksim Lapshin

ну это в теории так и так надо для всех аллоцируемых термов кроме атомов

ну да, вон выше я нашел пост где они подтверждают что это грязно

источник

19:09пожаловаться #7

ML

Maksim Lapshin in ErlangRus

Сергей Иванов

ну да, вон выше я нашел пост где они подтверждают что это грязно

У них все ядро в статичных атомах :)

источник

19:11пожаловаться #8

СИ

Сергей Иванов in ErlangRus

Maksim Lapshin

У них все ядро в статичных атомах :)

сделали бы уже без env , что бы не парить людей. а вот от аллокаций в контексте env я бы не отказался. что-бы он сам грохал пул связанныё с контекстом

всмысле термы он так и делает, а еще бы enif_alloc(env, size)

источник

19:12пожаловаться #9

СИ

Сергей Иванов in ErlangRus

хотя можно же binary для этого использовать

источник

19:14пожаловаться #10

ML

Maksim Lapshin in ErlangRus

Сергей Иванов

сделали бы уже без env , что бы не парить людей. а вот от аллокаций в контексте env я бы не отказался. что-бы он сам грохал пул связанныё с контекстом

всмысле термы он так и делает, а еще бы enif_alloc(env, size)

ага, binary подходит вроде

источник

19:14пожаловаться #11

СИ

Сергей Иванов in ErlangRus

Maksim Lapshin

ага, binary подходит вроде

а при интенсивном выделении сборщик не будет пухнуть? как он там ссылки считает

источник

20:32пожаловаться #12

ML

Maksim Lapshin in ErlangRus

Сергей Иванов

а при интенсивном выделении сборщик не будет пухнуть? как он там ссылки считает

Так если не отдавать бинарь эрлангу, а держать его внутри нифки, то это все на твоей совести

источник

21:09пожаловаться #13

СИ

Сергей Иванов in ErlangRus

Maksim Lapshin

Так если не отдавать бинарь эрлангу, а держать его внутри нифки, то это все на твоей совести

всмысле на моей совести? у него же нет методов free, я исопльзую бинари как временной пул памяти в контексте вызова nif

enif_make_new_binary

и надеюсь что beam грохнет всю эту память после вызова nif

источник

21:12пожаловаться #14

ML

Maksim Lapshin in ErlangRus

Сергей Иванов

всмысле на моей совести? у него же нет методов free, я исопльзую бинари как временной пул памяти в контексте вызова nif

enif_make_new_binary

и надеюсь что beam грохнет всю эту память после вызова nif

Нее. Enif_release_binary и что-то типа keep_binary

источник

22:19пожаловаться #15

СИ

Сергей Иванов in ErlangRus

Maksim Lapshin

Нее. Enif_release_binary и что-то типа keep_binary

это для enif_alloc_binary, а enif_make_new_binary аллоцирует в контексте env , поэтому сборщик должен его подчистить после выхода из nif ведь ссылаться на него никто не будет.
по крайней мере я течей не заметил

источник

22:26пожаловаться #16

ML

Maksim Lapshin in ErlangRus

Сергей Иванов

это для enif_alloc_binary, а enif_make_new_binary аллоцирует в контексте env , поэтому сборщик должен его подчистить после выхода из nif ведь ссылаться на него никто не будет.
по крайней мере я течей не заметил

Да, я не заметил

источник

22:29пожаловаться #17

2019 November 11

СИ

Сергей Иванов in ErlangRus

вопрос по поводу оптимизации - вот если app.src очень большой, и там есть некий param значение которого нужно опрашивать очень часто и во многих местах
application:get_env(param) - erlang умеет это оптимизировать если нет, то есть ли способ ускорить это не наворачивая везде код по передаче вычисленного значения? там ведь надеюсь не перебор листа

источник

12:52пожаловаться #18

СИ

Сергей Иванов in ErlangRus

будет ли application:get_key быстрее?

источник

12:54пожаловаться #19

MW

Mike Wazowski in ErlangRus

Сергей Иванов

вопрос по поводу оптимизации - вот если app.src очень большой, и там есть некий param значение которого нужно опрашивать очень часто и во многих местах
application:get_env(param) - erlang умеет это оптимизировать если нет, то есть ли способ ускорить это не наворачивая везде код по передаче вычисленного значения? там ведь надеюсь не перебор листа

Там же ets внутри. Куда уж быстрей...

источник

12:56пожаловаться #20