def handle_info(:tick, items) do
items2 = do_job(items)
tick()
{:noreply, items2}
end
In “do_job” I need to a) iterate throug items, b) make an http request which can take long and c) depending on a response, update a database and finish with the current item by removing it from “items” or merely update the database:
def do_job(items) do
Enum.each(items, fn(a) -> # or Enum.map
Task.start fn ->
case external_request(a) do
{:terminate, data} ->
Repo.update(....)
remove(a) # send a message to this GenServer to remove itself
{:continue, data} ->
Repo.update(....)
end
end
end)
end
Even if I had Enum.map, how would I return a value fro do_job since it creates Task for each one and executes asyncronously?
Do I have to return it at all? I think I do because handle_info should return a tuple with a list of items in case of success
Should I use Task.start or maybe better Task.async and wait? If so, how exactly for my case? Yet the #2 will remain.
Can you talk about your use case more? Your question is largely about how to implement a particular approach, but that approach may not be the best for what you’re doing. If you tell us what you’re trying to do, it will likely help us to give you a better answer.
As your do_job/1 is right now it transforms (maps) a set of items to a set of tasks. If you want values from the tasks then have the task callback either send a message or return a value and await on the tasks.
You always have a return, right now you are returning a list of tasks equal to the original items.
It is not recommended to await a long-running task inside an OTP behaviour such as GenServer. Instead, you should match on the message coming from a task inside your GenServer.handle_info/2 callback.
Having a list of items, iterate over them send an http request. After a response from a remote server has been received, update a value in a database. Also depending on a response , delete delete that value from a list or do the next iteration.
I suspect Ben’s request is motivated by the X-Y Problem - prompted by your handle_info/2 function which, without context can seem peculiar for the following reasons:
The primary design objective of a GenServer is usually handled via it’s handle_call/3 and handle_cast/3 callbacks. handle_info/2 is primarily used to process raw “fringe” messages that aren’t generated via call/3 and cast/2.
There seems to be an external message source emitting :tick messages for this GenServer. Why isn’t cast/2/handle_cast/2 being used instead?
The GenServer state is simply a list of items that seem to be “polled” for some reason. What’s stopping those :tick messages from coming in faster than those tasks completing? You could be starting tasks on items that previous tasks end up deleting. Wouldn’t it make more sense for the GenServer to manage it’s own “tick” based on when all the previous task complete?
Basically that handle_info function looks “fishy” without a larger context that may explain why it is the way it is.
In may make sense to cast/2 a :do_job request from the handle_info/2 callback so that the GenServer's primary responsibility is in a handle_cast/2 callback (rather than in handle_info).
Depending what you are doing it may also make sense to store the “item” together with it’s last task in the GenServer state so that you can skip items with tasks that haven’t completed yet - if that matters in your use case.
Task.create is not a function. Consider Task.start instead.
Enum.each returns :ok, not a list. Unless you’re updating items, you do not need to return an updated items. You can simply pass items straight through:
def handle_info(:tick, items) do
tick()
do_job(items)
{:noreply, items}
end
when I modify a list or state by adding or removing an element, what makes GenServer know that a list has changed and pickup a new list or state? For example:
def add_item(x) do
GenServer.cast(MODULE, {:add, a})
end
def handle_cast({:add, a}, state) do
state ++ a
end
How does state ++ a make GenServer take a return value and update the state so that the state will contain one element more after that?
Task.async and Task.await are used when you wish to compute a value asynchronously and then retrieve that value. I don’t think you’re trying to do that here, though I may be wrong.
That handle_cast({:add, a}, state) function will fail. You need to return {:noreply, updated_state}. Additionally, state ++ a is not the proper way to add an item to a list. Use [a | state] to prepend (fast) and state ++ [a] to append (slow).
Using Task.start will still perform the task asynchronously, you just won’t be given a reference to retrieve the return value of the task at a later point.
yes[quote=“net, post:17, topic:4854, full:true”]
That handle_cast({:add, a}, state) function will fail. You need to return {:noreply, updated_state}. Additionally, state ++ a is not the proper way to add an item to a list. Use [a | state] to prepend (fast) and state ++ [a] to append (slow).
[/quote]
prepend, append, slower, faster – that doesn’t matter and my question isn’t about that.
