[erlang-questions] enif_send rules questions

Sverker Eriksson <>
Wed Jan 25 18:24:16 CET 2017


The lifetime of the thread doesn't matter.


"env    The environment of the calling process. Must be NULL only if 
calling from a created thread."

enif_send(env, ...) uses argument 'env' to make assumptions about
the thread context, such as seized locks for example. When calling
from an Erlang process, the main lock of the process is held.

/Sverker


On 01/25/2017 05:14 PM, Daniel Goertzen wrote:
> 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
>>



More information about the erlang-questions mailing list