search

erlang / otp

Erlang/OTP
http://erlang.org
Apache License 2.0
11.38k stars 2.95k forks source link

ERL-337: Guarantees in the NIF api #3162

Closed OTP-Maintainer closed 3 years ago

OTP-Maintainer commented 7 years ago

Original reporter: hansihe Affected version: Not Specified Component: Not Specified Migrated from: https://bugs.erlang.org/browse/ERL-337

I am working on a Rust library that aims to make NIFs safer to write. I have found a couple of things that could help greatly improve the experience of writing NIFs. They are listed in order of what I believe is decreasing importance.

* Offer a guarantee in the documentation that nothing bad will happen if the return value of enif_schedule_nif is not returned from the NIF function. This would greatly ease writing a completely safe Rust wrapper for this without runtime overhead. This is the one thing I believe to be most important.
* Guarantee that terms are not garbage collected between enif_schedule_nif calls. This would make it much more pleasant to write NIFs that reschedule themselves in many cases, since the user would not need to collect all terms, and pass them as an explicit argument to the rescheduled function every time.
* Allow the same Env to be used across several enif_schedule_nif calls. This, combined with the entry above, would make a coroutine based method for rescheduling easier to use. Would make it easier to implement and use something that yields to the scheduler at any point in the call stack.

Please note that I am not expecting anything to be implemented, I am only looking for feedback as to why these would be a good/bad idea. Thanks for taking the time to look at this.
OTP-Maintainer commented 7 years ago

sverker said:

I'm closing this as it's not of high priority for us.

Here is some late feedback:

#1 Would cost runtime overhead. If not payed in your rust wrapper it would have to be always payed by the NIF calling beam instruction.

#2 I can see the use case for this. We already disable GC for some yielding BIFs. To expose it in NIF API would limit possible heap implementations as you need a way to allocate new heap without GC (which was actually quite expensive a number of major releases ago). But maybe it would be worth it.

#3 I don't quite understand, but it sounds like it would cost overhead as process bound ErlNifEnv are today stack allocated.