While a nif is running on a scheduler its utilization will be plotted as 100%. This is normal.
If the NIF is running on a dirty scheduler it should not block regular schedulers. Here’s how I tested it locally:
- In the C code of the dirty NIF function I added
sleep(10); - I started the shell with
ELIXIR_ERL_OPTIONS="+S 1" iex -S mix(to make sure there’s just one scheduler and one dirty CPU scheduler) - From the shell I started the nif as
spawn(&my_nif/0) - As soon as process was spawned the iex shell was responsive and I was able to start the observer.
If you invoke a lot of longer-running dirty nifs concurrently, you may end up occupying all the dirty scheduler threads, which might block some other operations. For example, length will switch to dirty schedulers for larger list, and if all schedulers are busy for a couple of seconds, length will be blocked. I was able to reproduce this by spawning a long-running NIF, and then invoking length(Enum.to_list(1..1_000_000)) which blocked until NIF finished.
Based on the description of the scenario this looks like a case where port might be a better fit.
