[erlang-questions] enif_send rules questions

Daniel Goertzen <>
Wed Jan 25 17:14:12 CET 2017


I see another scenario here:  What happens in the context of enif_send() in
a scoped thread?  That is, in my NIF function I spin up a thread that does
an enif_send() and exits before my NIF function returns.  The process
environment is in fact in scope for the enif_send, but I'm also in a
created thread.  Should I plug in the process environment or null?

On Sat, Jan 14, 2017 at 1:04 AM Jason Orendorff <>
wrote:

> On Fri, Jan 13, 2017 at 10:09 AM, Sverker Eriksson <
> > wrote:
>
> On 01/12/2017 08:21 PM, Jason Orendorff wrote:
>
> 4.  We suspect it's actually totally safe to pass a process-independent
>      environment as the first parameter, regardless of whether there's a
>      "calling process" or we're "calling from a created thread". Is it?
>      If so, would you accept a patch to document that that's OK?
>
> I'm not super excited about such a guarantee, at least not right now.
>
>
> Thank you for the quick, thoughtful response. I appreciate your time.
>
> Is there a way to enforce this rule for our users that we've missed? When
> our `send` method is called, I think we have to figure out if there's a
> current
> calling process, and if so, its environment. I don't see a way to do it
> without
> storing that information in TLS ahead of time -- at a cost to every NIF
> call.
>
> We could make code that runs on created threads statically different from
> code that runs in the Erlang scheduler's threads, e.g. by making
> `NifCallEnv`, `AllocatedEnvInNifThread`, and `AllocatedEnvInCreatedThread`
> three different types, of which only 2 have `.send()` methods. But this
> seems horrible.
>
> We have considered several possible approaches, all about as bad as that.
>
> Thanks,
> -j
>
> _______________________________________________
> erlang-questions mailing list
> 
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20170125/83fefd74/attachment.html>


More information about the erlang-questions mailing list