kuon
I wrote a NIF which have function that can take a long time to run. To prevent the scheduler from being overloaded with long running functions (even if marked at dirty), I made my NIF threaded and it sends message back to erlang using enif_send.
I want to make those call synchronous from a “programmer point of view”. Similar to a Process.sleep() call.
I was wondering what was the best approach. To avoid messing with the caller message inbox and to have an isolated process to receive the message, I thought of using something like this:
task = Task.async(fn ->
call_nif(self())
receive do
<wait for nif response>
end
end)
Task.await(task)
Would that be a good approach?
Where Next?
Trending in Questions
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
We build reliable cloud platforms for business-critical systems.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #ai
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming
Our Sponsors
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Practical resources that improve the lives of professional developers.
Producing high quality Elixir screencasts since 2017.
**Building the future of software with AI, trust, and human connection.**
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 7- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
krasenyp
It could work but in my opinion it’s best to use a yielding NIF or spawn an extra process and use local means of communication.
kuon
My NIF is blocking and it is hard to make it non blocking, so I wrapped the entire function into a C thread, my NIF now spawn the thread and return immediately, then the thread sends the message. It seems to be a recommenced architecture in the documentation.
Now my question is more about the user API which I want to make synchronous for API simplificy sake, so I thought of this task trick (which works fine). But I was wondering it was the right approach or if there was a more idiomatic way to do it.
In fact it is to make an async call synchronous in general, not really tied to a nif.
benwilson512
Why wrap it in a task at all? Can you simply have a function that calls the NIF and then does a receive right after?
What does this NIF do btw? How long does it run?
kuon
The calling process might have other messages in its inbox when I call this function, I didn’t want to mess with that. This nif does some GPU inference, it runs for about 5 seconds.
I know it could/should be an external port, but using nif I get all serialize/deserialize for free and it is very practical.
LostKobrakai
Namespacing and a selective receive would to that.
kuon
So I can just do
receive do {:my_namespace, …} → <we are done> endand it will not mess with the inbox? I wasn’t sure of that.LostKobrakai
I’ll remove the matches message from the inbox – but it’ll leave anything else as is.