11 ms·

I’m not expert here but I think most of that risk is mitigated these days since BEAM introduced Dirty Schedulers/Dirty NIFs for any NIFs that take over 1ms to e

I’m not expert here but I think most of that risk is mitigated these days since BEAM introduced Dirty Schedulers/Dirty NIFs for any NIFs that take over 1ms to execute… I think this isolates (or can isolate) their issues to only effecting other work on the same Dirty scheduler, aka other Dirty NIFs… Few quick links: https://www.erlang.org/doc/man/scheduler.html https://www.erlang.org/doc/man/scheduler.html https://medium.com/@jlouis666/erlang-dirty-scheduler-overhead-6e1219dcc7 https://medium.com/@jlouis666/erlang-dirty-scheduler-overhea... https://bgmarx.com/2018/08/15/using-dirty-schedulers-with-rustler/ https://bgmarx.com/2018/08/15/using-dirty-schedulers-with-ru...

toast0 4y ago
Dirty schedulers isolate the potential scheduling issues, but there's no memory isolation between NIFs and the rest of the BEAM state, so there's danger there.
- eproxus 4y ago
  Best practice for doing this with the BEAM (the Erlang VM) is to just run two VMs, one for your app code and a “dirty” one that is allowed to crash and be restarted without bringing down your app VM.
  - toast0 4y ago
    If you're considering running a second (or multiple) BEAM for your nifs, you should also consider running your native code as a c-node or a port program.
    - OkayPhysicist 4y ago
      A compelling use case is where your website and numerical engine are running on different machines. In that circumstance, your main application is already isolated from issues on the numerical engine.