Follow `enif_send` contract.

[rusterlium]

Follow `enif_send` contract.

[jorendorff]

Options:

1. What the current send branch does. This is sound, and it supports both enif_send use cases ("calling process" and "created thread"), but it incurs measurable overhead on every NIF call.
2. We can add a bool to NifEnv telling whether or not it's the "environment of the calling process". The bit would be true for envs created by handle_nif_call and false for envs created by OwnedEnv::run etc. This would impose some overhead, not on every NIF call, but on everything you do with a NifEnv (no guess whether this is better or worse than option 1). Plus this is a half solution. It works only for "calling process" cases, i.e. when the bit is set. If it's not set, we might be either in a "calling process" or a "created thread" situation, and we have no way of knowing which.
3. We can create a different thread-local variable, a bool that is set true by ThreadSpawner::spawn() to mark "created" threads. This too is a half solution, but the other half: if we're in a calling process, we know it's safe to call enif_send(null, ...). If not, we don't know if env is the correct environment to pass to enif_send or not.
4. We could do both option 2 and option 3.
5. We can mark NifEnv::send() and trait JobSpawner as unsafe.
6. We can add some kind of flag that you have to set in your rustler_export_nifs if you want to use env.send(), so you only pay the overhead if you're actually planning to send messages. If you don't set the flag, the thread-local variable will be None and .send(), seeing this, can just panic.

[scrogson]

Looks like another option would be to use enif_thread_type

[goertzenator]

Thanks for posing this in the erlang-questions lists. enif_send is the only safety hole that I haven't solved yet. If you learn anything new, please do record it here for posterity.

Maybe once the dust has settled on OTP-20 (and they are juggling quite a bit in the NIF code) we can see if there are any changes/additions on the Erlang side that will allow safe enif_send.

[hansihe]

An alternative to option 6 would be to use cargo conditional compilation. If the user wants to use send, they add the send feature to the Cargo.toml, and the code for the feature only gets compiled in if the user explicitly enables the feature. This would completely remove all runtime cost when the feature is disabled, and possibly make the implementation simpler.

[jorendorff]

Right -- I forgot about that. I'll do that.

[goertzenator]

@scrogson Nice find! enif_thread_type first appeared in OTP-19 and is provided by erlang_nif-sys = ">=0.5.3".