Hacker News Reader

it is almost trivial to write nifs which yield and continue, enif_schedule_nif exists for this purpose.

nifs are ideal for operations which mutate binaries, eg hashing or unmasking a websocket frame

I didn't just mean the mere ability to yield, which isn't that complicated; I meant code supporting the common use cases around having a long-running NIF, such as the person I replied to's comment about having some sort of build in support for being able to answer back to a PID or something. I could easily imagine a NIF library that provided an easy ability to set up an independent thread pool and work sharing mechanism specific to that NIF, which sends answers back to given PIDs, has timeout support or the ability to query it for progress, etc. All fairly straightforward stuff to expect to develop over time, but in a world where long running NIFs are too dangerous to hardly even contemplate, they haven't developed yet.

There's some some parameters in there that are going to be tricky to set up correctly (number of workers in the pool for a given NIF has a lot of implications at scale), but in the end it's not significantly different than communicating to a separate process on the some machine; it's all the same resources being used.

Yeah... but that hasn't existed for very long. :-)

Reply on news.ycombinator.com