[erlang-questions] nif driver c code must be reentrant?

[Rapsey]

My experience with R16B and frequent NIF calls with bump_reductions is
very negative. Without bump_reductions even worse. At the moment I
would not use NIFs for anything. Everything will look ok, but once
server starts getting busy it will completely stop working.


Sergej

On Tue, May 21, 2013 at 9:54 AM, Gleb Peregud <gleber.p@REDACTED> wrote:
> I believe there is no API nor technical mean to make NIFs reentrant
> currently. Hence you should refrain from making NIFs which can run for
> a long time.
>
> But if you want to make NIFs more friendly to the scheduler, you can
> use erlang:bump_reductions/1 from Erlang wrapper of a NIF call.
>
> On Tue, May 21, 2013 at 4:14 AM, Τ³çŸj <wckbluesky@REDACTED> wrote:
>> hi~
>>
>> I try to design some nif codes recently and I reading a book " Erlang and
>> OTP in Action" now. In this book, chapter 12, "Integrating with foreign code
>> using ports and NIFs", page 313, section "Making a linked driver".
>>
>> I found some words:
>> "
>> Because all these instances execute
>> within the memory of the Erlang VM, possibly running as different threads, the driver
>> code must be designed to be reentrant¡ªexecutable by multiple simultaneous callers¡ª
>> and must not depend on global variables or locks.
>> "
>>
>> and then, this book give some methods to avoid this problem, something like
>> not to use global variables, and use driver_alloc, driver_free to allocate
>> memory dynamically.
>>
>> of course, these words were placed into the section "Making a linked
>> driver"
>>
>> My questions is:
>>
>> 1) Is nif driver c code has the same problem? That is, nif driver c code
>> must be designed to reentrant?
>> 2) I know that, nif calling will block the VM until the driver c code
>> returns, Is that other problems we must notice when using nifs?
>>
>> And if nif driver c code must be designed to reentrant, then I will have
>> anther question.
>> I read this words from erlang.org
>>
>> "
>> NIFs are called directly by the same scheduler thread that executed the
>> calling Erlang code. The calling scheduler will thus be blocked from doing any
>> other work until the NIF returns
>> "
>>
>> That is, calling scheduler is driven by the same thread, so the calling
>> will be blocked.
>> Then why should we designed our nif code to be reentrant?
>>
>>
>> The e-mail is little long, thanks for reading, and I do hope to receive any
>> helpful messages.
>> Thanks!
>>
>>
>>
>>
>> Best Regards
>> ckwei
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions