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.