3 ms·
> to write a NIF that could somehow yield back and then be "continued" later would be a royal pain. I know... nothing... about the NIF interface, but the way
by quodlibetor 10y ago
> to write a NIF that could somehow yield back and then be "continued" later would be a royal pain.
I know... nothing... about the NIF interface, but the way that I would want this to work wouldn't involve NIF resumption at all, but rather for NIFs to be able to put responses back on a channel.
Unfortunately neither quick internet searches nor searching the rustler docs revealed anything about a NIF/channel interface. I'm not sure how feasible it is to pass a channel into a nif and allow it to pass that into some thread and return, nor how good of an idea that would be.
- im_down_w_otp 10y agoThis 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!