4 ms·
This wouldn't make sense because NIFs are supposed to be just straight function calls that provide immediate returns. It's a blocking interface. If you want th
by im_down_w_otp 10y ago
This wouldn't make sense because NIFs are supposed to be just straight function calls that provide immediate returns. It's a blocking interface.
If you want the behavior you're talking about you would communicate via ports, or you'd write a NIF that maintained its own off scheduler thread(s), returned immediately, but kept a reference to the calling pid, and then sent a message to that pid at some later date. Several IO related NIFs do that today.
That's actually an excellent use for Rust in this case because it can help you make that multi-threaded implementation safer and more reliable.
- quodlibetor 10y agoThat all makes sense, and the immediate return + threads solution you describe sounds like what I was imagining, I just didn't have the context to use the correct parts of the Erlang FFI. I'm glad that there is a pattern for that kind of thing!