Hi @tessi, thanks for taking time to write this approach. I also played around same idea in the past (in C though).

Just want to highlight the risks involved if someone is considering

• since mutex does not compose well, its easy to end-up with deadlocks. Especially if the callback is not internal function but something given by the user of the library (consider a callback calling another NIF).
• its tricky to handle errors, “let-it-crash” does not work well with this, since we have to unblock the thread no matter what happens to the callback.
• forces process at erlang/elixir side and thread at NIF side. And most likely we need thread pooling at NIF side
• needless to say its not very efficient if you are calling callback often - due to all the context-switching & synchronizations involved.

I think there were few more but not able to recall at the moment.

Another reference: [erlang-questions] Calling Erlang functions from NIFs

Thanks! Wow, @tessi that is very impressive work. Your explanation of the ResourceArc is really helpful for me and I’d love to see clearer explanations like that in the official documentation. That’s really where I’m hurting the most. Definitely simplified in 0.22.0-rc though.

Probably not terribly useful for what I’m working on to call into Elixir that way, but seeing how you did it is extremely enlightening.

Thanks José! I suppose I’ll cross that bridge when I get there then. Won’t hurt to start with serialise/apply/deserialise. I’m not sure if pyo3’s approach of embedding a Python interpreter in the binary is particularly reasonable anyway. I may be imagining bottlenecks in copying before I’ve proved the problem anyway.

Hi,

I am pretty sure it’s possible to call from a NIF into elixir because I’m doing just that in wasmex

Someone asked about how I do that in a GitHub issue where I explained the why’s and how’s in a little more detail:

Feel free to ask away if there is any questions

Thanks @akash-akya

your points are very valid. The whole thing is a big dance for just calling into Elixir. But it’s possible. I think in Rust, the thread handling part is a little more safe, but still deadlocks are possible. (we could build in timeouts, though, so that things eventually return).

And yes, it’s not super efficient. It could be much more efficient and more easy to build if we settle for async calls (message sends) only.