[erlang-questions] NIF wishes

Hans Nilsson R hans.r.nilsson@REDACTED
Tue Dec 8 18:47:06 CET 2009


If I remember correctly, large binaries are shared between processes in 
a separate area.  So a change will stay in the binary both in the 
calling process and in other processes who have a reference to the 
binary or to parts of it.

/Hans Nilsson

Rapsey skrev:
> Speaking of binaries and NIF. If you send one to a NIF function, you get a
> direct pointer to the binary and can modify it in-place. How dangerous is
> this?
>
>
> Sergej
>
> On Tue, Dec 8, 2009 at 5:50 PM, Hans Nilsson R
> <hans.r.nilsson@REDACTED>wrote:
>
>   
>> I have been playing with the NIF facility in R13B03 and I have some
>> comments. The implementation is very stable, as usual with experimental code
>> from Erlang/OTP!  And very fast....
>>
>> I have a large binary which I pass into a nif, which processes a part of it
>> and returns the result and the unprocessed part of the binary.  The
>> unprocessed part is then input to the nif again and so on.
>>
>> Wish 1:
>> Now, in the nif, to make a copy of the unprocessed part and make a new
>> binary is time consuming, so some function enif_make_sub_binary(env, bin,
>> from, to) would be useful.
>>
>> Wish 2:
>> When the nif shall return a part of the binary as a string or a binary, the
>> functions enif_make_atom and enif_make_string  assumes that the part is
>> zero-terminated.  It is of course possible to save the character, write a
>> zero, call the enif-function and then write back the original character, but
>> it is of course dangerous to modify in place in a binary...  The alternative
>> of copying the characters to a buffer is slow.
>>
>> Therefore I'd like to have some  enif_make_string_n(env, char *p, int
>> length) as well, analogous to the c-library functions strcpy and strncpy.
>>
>> /Hans Nilsson
>>
>>
>> ________________________________________________________________
>> erlang-questions mailing list. See http://www.erlang.org/faq.html
>> erlang-questions (at) erlang.org
>>
>>
>>     
>
>   



More information about the erlang-questions mailing list