[erlang-questions] Add a new data structure to erlang VM.

Constantin Kulikov <>
Wed Jul 13 10:31:28 CEST 2016


> This seems to work because you are lucky. :)

Yes, it's crashing randomly after a number of pushes/pops.

> You can think of ErlNifEnv as an array, and ERL_NIF_TERM as an index into
that array.  The indexes can be copied however you like, but they are only
valid on the original array.  Your code is storing an index, but is not
bringing along the original array.  In some cases this will still work
(atom terms don't need their environment), or seem to work, but you've
planted the seeds of a future mysterious segfault.
> Now you can't keep the ErlNifEnv from your NIF function; you need to use
enif_alloc_env() and then copy terms into that ErlNifEnv with
enif_make_copy().

Thanks for the clarification.


On 12 July 2016 at 15:53, Daniel Goertzen <> wrote:

> This seems to work because you are lucky. :)
>
> You can think of ErlNifEnv as an array, and ERL_NIF_TERM as an index into
> that array.  The indexes can be copied however you like, but they are only
> valid on the original array.  Your code is storing an index, but is not
> bringing along the original array.  In some cases this will still work
> (atom terms don't need their environment), or seem to work, but you've
> planted the seeds of a future mysterious segfault.
>
> Now you can't keep the ErlNifEnv from your NIF function; you need to use
> enif_alloc_env() and then copy terms into that ErlNifEnv with
> enif_make_copy().
>
>
>
> On Sun, Jul 10, 2016 at 12:17 PM Constantin Kulikov <>
> wrote:
>
>> This seem to work
>> https://gist.github.com/Bad-ptr/3ea0d6d65ae18b5b68c6cb15a96fef8e .
>>
>> However the documentation says that:
>> > All terms of type ERL_NIF_TERM belong to an environment of type
>> ErlNifEnv. The lifetime of a term is controlled by the lifetime of its
>> environment object.
>>
>> > Variables of type ERL_NIF_TERM can refer to any Erlang term. This is an
>> opaque type and values of it can only by used either as arguments to API
>> functions or as return values from NIFs. All ERL_NIF_TERM's belong to an
>> environment (ErlNifEnv). A term can not be destructed individually, it is
>> valid until its environment is destructed.
>>
>> > The environment is only valid in the thread where it was supplied as
>> argument until the NIF returns. It is thus useless and dangerous to store
>> pointers to process bound environments between NIF calls.
>>
>> So, it is not clear to me is it safe to store an ERL_NIF_TERM(in a form
>> as it passed to a NIF function) in a datastructure created by a NIF
>> function? And does the GC aware that this terms must not be collected ? Etc.
>>
>>
>> On 9 July 2016 at 21:59, Steve Vinoski <> wrote:
>>
>>>
>>>
>>> On Sat, Jul 9, 2016 at 1:54 PM, Constantin Kulikov <>
>>> wrote:
>>>
>>>> If I want to add a new datastructure to erlang(my local fork of the
>>>> erlang-otp from github), what should I do? Yes, I mean a C-level module
>>>> realization.
>>>>
>>>> Let's say I want to add a double linked list(just for simplicity)
>>>> module with an interface like that:
>>>> dlist:new() -> ?some king of reference to a list?
>>>> dlist:push(item) -> ?reference to a list?
>>>> dlist:pop() -> {item, ?reference to a list?}
>>>> etc...
>>>>
>>>> Is it possible at all? Has anyone ever tried to do something like this?
>>>> What definitions to what files should I add? How must I allocate my
>>>> data structure? How must I reference items in it?
>>>> Can someone point me to source locations where erlang's list/ets
>>>> table/tuple operations(creating a new, storing a reference to objects)
>>>> defined?
>>>>
>>>
>>> See
>>>
>>> http://erlang.org/doc/tutorial/nif.html
>>> http://erlang.org/doc/man/erl_nif.html
>>>
>>> --steve
>>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> 
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20160713/dc957c40/attachment.htm>


More information about the erlang-questions mailing list