[erlang-questions] enif_send rules questions
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 <>
> 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
> calling process, and if so, its environment. I don't see a way to do it
> storing that information in TLS ahead of time -- at a cost to every NIF
> 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.
> erlang-questions mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions