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

韦崇焜 wckbluesky@REDACTED
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 
memory dynamically.
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 
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.
Best Regards

More information about the erlang-questions mailing list