[erlang-questions] nif driver c code must be reentrant?
Tue May 21 04:14:24 CEST 2013
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
of course, these words were placed into the section "Making a linked
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
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
More information about the erlang-questions