<div dir="ltr">1) Is nif driver c code has the same problem? That is, nif driver c code<br>must be designed to reentrant?<div><br></div><div style>Yes</div><div><br>2) I know that, nif calling will block the VM until the driver c code<br>
returns, Is that other problems we must notice when using nifs?<br><div class="gmail_extra"><br></div><div class="gmail_extra" style>See <a href="http://www.erlang.org/doc/man/erl_nif.html#WARNING">http://www.erlang.org/doc/man/erl_nif.html#WARNING</a></div>
<div class="gmail_extra"><br></div><div class="gmail_extra" style>/Dan</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 21, 2013 at 4:14 AM, Î¤³çŸj <span dir="ltr"><<a href="mailto:wckbluesky@yahoo.com.cn" target="_blank">wckbluesky@yahoo.com.cn</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">hi~<br>
 <br>
I try to design some nif codes recently and I reading a book " Erlang and<br>
OTP in Action" now. In this book, chapter 12, "Integrating with foreign code<br>
using ports and NIFs", page 313, section "Making a linked driver". <br>
 <br>
I found some words:<br>
"<br>
Because all these instances execute<br>
within the memory of the Erlang VM, possibly running as different threads, the driver<br>
code must be designed to be reentrant—executable by multiple simultaneous callers—<br>
and must not depend on global variables or locks.<br>
"<br>
 <br>
and then, this book give some methods to avoid this problem, something like<br>
not to use global variables, and use driver_alloc, driver_free to allocate<br>
memory dynamically.<br>
 <br>
of course, these words were placed into the section "Making a linked<br>
driver"<br>
 <br>
My questions is:<br>
 <br>
1) Is nif driver c code has the same problem? That is, nif driver c code<br>
must be designed to reentrant?<br>
2) I know that, nif calling will block the VM until the driver c code<br>
returns, Is that other problems we must notice when using nifs?<br>
 <br>
And if nif driver c code must be designed to reentrant, then I will have<br>
anther question.<br>
I read this words from <a href="http://erlang.org" target="_blank">erlang.org</a><br>
 <br>
"<br>
NIFs are called directly by the same scheduler thread that executed the<br>
calling Erlang code. The calling scheduler will thus be blocked from doing any<br>
other work until the NIF returns<br>
"<br>
 <br>
That is, calling scheduler is driven by the same thread, so the calling<br>
will be blocked.<br>
Then why should we designed our nif code to be reentrant?<br>
 <br>
 <br>
The e-mail is little long, thanks for reading, and I do hope to receive any<br>
helpful messages.<br>
Thanks!<br>
 <br>
 <br>
 <br>
 <br>
Best Regards<br>
ckwei<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div><br></div></div></div>