Calling Elixir in Rust?

As far as I know it is not possible to call Elixir/Erlang functions from C/Rust code.

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.

Not sure how helpful this is, but if you can link C libs and you want to serialise stuff, there’s Erlang Interface / docs

You can then from C encode terms:

void respond_with_window(osea_CTX *osea_ctx) {
  char msg[2], finish[2];
  ei_x_buff buf;
  ei_x_new_with_version(&buf);

  msg[0] = RSP_WINDOW;
  finish[0] = '\n';
  ei_x_format_wo_ver(
	      &buf,
	      "{~l,~i,~i,~l,~i}",
	      osea_ctx->egl_native_window_type,
	      osea_ctx->osea_win.width,
	      osea_ctx->osea_win.height,
	      osea_ctx->toolbar.height,
	      osea_ctx->toolbar.visible
	      );


  write(1, msg, 1);
  write(1, buf.buff, buf.buffsz);
  write(1, finish, 1);
  ei_x_free(&buf);
};

Which encodes a tuple with five elements, {long/unsigned, int, int, long/u, int}.
And from the Elixir/Erlang side call binary_to_term(Rem), which decodes it into a normal tuple.

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:
https://github.com/tessi/wasmex/issues/256#issuecomment-848339952

Feel free to ask away if there is any questions

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 @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.

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.

Wow that’s super impressive. It’s giving me ideas though, I think there might be a clever and safe way of doing this in zigler by yielding first, and storing the frame, then resuming once the result term has come back. If the owning process is killed, the resource can be freed and the yield will exit, triggering cleanup of allocated memory, etc.