You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to Erlang-Questions Questions
Sverker Eriksson
unread,
May 4, 2012, 10:11:01 AM5/4/12
Reply to author
Sign in to reply to author
Forward
Sign in to forward
Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to Max Lapshin, Erlang-Questions Questions
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"
/Sverker, Erlang/OTP
Jeff Schultz
unread,
May 4, 2012, 10:51:40 AM5/4/12
Reply to author
Sign in to reply to author
Forward
Sign in to forward
Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to Erlang-Questions Questions
On Fri, May 04, 2012 at 03:35:17PM +0200, Lukas Larsson wrote:
> If I understand you correctly the answer is yes.
> I think the crypto implementation[1] does exactly this and since
> Sverker wrote both crypto and the NIF support I would say that it is
> safe :)
> On Fri, May 4, 2012 at 3:22 PM, Max Lapshin <max.l...@gmail.com> wrote:
> > Is there a way to cache atoms in NIF?
> > Is it ok just to store in static variable result of enif_make_atom ?
Seems unlikely to remain true if EEP20 or atom GC is ever implemented.
It would be quite a chore to find all such instances then.