Tina
Hello!
I have one Dynamic Supervisor with 3 Gen Server actors (call them workers), and in parallel a Load Balancer actor. The Load Balancer actor receives a stream of data and sends in round robin fashion the data to be manipulated by the workers.
Now comes the problem. Speculative execution (at least the version I try to implement) states that given a task to 2 different actors, one of them will execute it faster and the other one should be stopped from finishing it (mid-process) and told to move on to the next task.
Solution 1: kill it with Process.exit(), the worker will be respawned and continue. But the further messages in the mailbox will be lost.
Solution 2: Part the process in several steps and log the progress on shared resource (be it a database or using Agent). When trying to move to the next one, look up if the other worker has finished and stop if so. But this adds additional computation time and not every process can be parted into several steps. Smells like overhead much.
Solution 3: Use a special function that, once the Load Balancer receives the answer from an actor, will be called so the second actor stops the message execution (if started) or never execute it (if still in queue).
Has anyone any idea of such a special function for Solution 3? I’ve spent like 2 days reading the documentation but did not come close to such. Or maybe there is a method to create such function that will force the Gen Server to at least stop mid-process and consider the new high-priority message?
Thanks!
Where Next?
Trending in Questions
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Courses that'll move you from confusion to "Aha, now I get it!"
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
- #elixirconf-us
- #ai
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming
Our Sponsors
Build Elixir applications with speed and confidence.
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!
Bringing learning, work and compliance together since 1987.
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 6- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
LostKobrakai
You cannot force another process from the outside to stop what it’s doing and read a message. You can only send it a message, which will queue like any other and needs to wait for the process to check its mailbox. So the best you could do is similar to your option 2, where the worker regularly checks its mailbox to see if its supposed to stop / drop work from the queue.
D4no0
The question is why would you give the same task to be executed to 2 different processes?
There is no concept of message priority, all messages are read from the mailbox sequentially, the only way for you to achieve this is to make your own abstraction on top of GenServers.
kwando
I’m not sure this is the bes approach but anyways, here is an idea:
Keep you worker responsive:
Tina
That was my first question too
It’s a learning task at a Real-Time Programming university course. We are simulating a case of real time processing of streams of data and in order to achieve faster results comes the Speculative Execution solution we should implement in this particular way. The situation is that having multiple resources with performance variation and a limited time the result should be received in, send the task to multiple actors, achieve the result in the fastest time possible and tell the other ones to drop it.
Tina
Thanks! I think the approach will make the Solution 2 better than it looks like now. :))
D4no0
Oh I see, the problem with your approach is that you need to guarantee that all those processes will run on a different scheduler, since each scheduler runs on a separate core, otherwise there is absolutely no gain from this approach as running them on the same core will just execute them concurrently by switching the context.