[erlang-questions] enif_send rules questions
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.
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 <jason.orendorff@REDACTED>
>> On Fri, Jan 13, 2017 at 10:09 AM, Sverker Eriksson <
>> sverker.eriksson@REDACTED> 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
More information about the erlang-questions