<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 26, 2016 at 1:41 PM, Ildar Khizbulin <span dir="ltr"><<a href="mailto:herr.hizel@gmail.com" target="_blank">herr.hizel@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Yep, including. I create simple example on<br>
<a href="https://github.com/hizel/enif_test" rel="noreferrer" target="_blank">https://github.com/hizel/enif_<wbr>test</a> with full code.<br></blockquote><div><br></div><div>What you're trying to do doesn't appear to be supported currently. The Erlang nif internals require the module name argument (second argument) of enif_open_resource_type() to be a null pointer (see <a href="http://erlang.org/doc/man/erl_nif.html#enif_open_resource_type">http://erlang.org/doc/man/erl_nif.html#enif_open_resource_type</a>). It generates an atom identifier for the resource type based on the calling module. You can see that code here:</div><div><br></div><div><a href="https://github.com/erlang/otp/blob/maint/erts/emulator/beam/erl_nif.c#L2012-L2013">https://github.com/erlang/otp/blob/maint/erts/emulator/beam/erl_nif.c#L2012-L2013</a><br></div><div><br></div><div>As a result, when your second module tries to take over the resource type, the enif_open_resource_type() implementation fails to find the resource you created in your first module, and so it ends up creating a new resource type instead. When you try to use this new type in your second module to retrieve the resource binary argument created by the first module, you get badarg because the two resource types are different types.</div><div><br></div><div>--steve</div><div><br></div></div></div></div>