undefined | Better HN

0 pointsweatherlight7mo ago0 comments

because the author self admitted they don't know C! One of the reason why people use the Beam VM is because its robust and fault tolerant.

a lot of the choice here are made at the expense of VM's health.

also why wouldn't anyone just use :disksup.get_disk_info/1. (Thats immediate) calling :disksup.get_disk_info/1 won’t mess with the scheduler in the way a custom NIF or a big blocking port might.

I see the above code/lib and just see reflags all over the place.

0 comments

leansensei7mo ago

The post explains why I don't want to use disksup. You have to start an extra application (os_mon) and configure disksup to update the starts more frequently than the default of every 30 minutes.

Do we really need to do all that instead of the equivalent of a df?

Agree about the C code, which is why the latest version (on GitHub, the HEAD, not yet released in Hex.pm) is now using Rust and Rustler.

weatherlightOP7mo ago

:disksup.get_disk_info/1 (from :os_mon) just calls into the underlying OS once, grabs the info, and returns it. It’s not a blocking “long-running monitor” the way a NIF doing I/O in a scheduler thread would be. https://www.erlang.org/docs/26/man/disksup#get_disk_info-1

^ just use this.

:disksup.get_disk_data/0, which caches results in the :disksup server that updates every N seconds (configurable) which is what you are referring to.. https://www.erlang.org/docs/26/man/disksup#get_disk_data-0

j / k navigate · click thread line to collapse