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

[Dan Gudmundsson]

If you have lengthy work that you can break it in several parts,
you can do easily like this:

lengthy_work(Data) ->
    case lengthy_work_impl(Data) of
Cont = {continue, _State} ->
    erlang:bump_reductions(1000000),
    lengthy_work_impl(Cont);
{finished, Result} ->
    Result
    end.

lengthy_work_impl(_) -> erlang:nif_error(undefined).




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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130521/4265c73f/attachment.htm>