I am writing a channel that receives certain events from mobile applications. When an event is received, it has to be stored in a data store, and published to a message bus: def handle_in(message, payload, socket) do event = build_event(message, payload, socket) store(event) publish(event) …

Just freehand but you may want to try something like this: def task_fun(:store, event), do: store(event) def task_fun(:publish, event), do: publish(event) def run_tasks(event) do # blocks until list is reified # :max_concurrency defaults to System.schedulers_online/0 MyApp.TaskSuperviso…

[image] fxn: Can you justify Task.Supervisor in this use case? From a design perspective as a “control enthusiast” I’d go even further and outsource the entire store/publish business to a separate process (perhaps in its own supervision tree), so that the handle_in only has to dispatch the ev…

[image] peerreynders: From a design perspective as a “control enthusiast” I’d go even further and outsource the entire store/publish business to a separate process (perhaps in its own supervision tree), so that the handle_in only has to dispatch the event (and event order between processes is gu…

FYI: This is just how my first “stab at it” would look like - I’m not implying that I’m in possession of some kind of gold standard. Would you for example have one supervisor for storage, one for publishing, two supervised processes per topic respectively (whose names are in the socket assigns?) …

[image] fxn: However, does that really need TaskSupervisor ? Would Task.start be enough? Note that on shutdown, when the endpoint supervisor takes down its children, the await call will wait for these two anyway. The genera rule is: always start processes under a supervisor. It gives two thin…

Thanks @josevalim :). I totally missed the caller monitors the task too, so the indirection through the supervisor to prevent tasks from crashing the WS is unnecessary, as shown in your example. I believe we lose the order guarantee, however. Let me explain: Events have a timestamp, and they have …

[image] josevalim: If the concern is code organization, then modules and functions are the correct level to address it, not processes. Code organization wasn’t my primary concern. Though I have to admit I somehow lost track of this fact : One channel server process is created per client, pe…

[image] peerreynders: You could queue pending events in the socket’s assigns . Wrap the two tasks in a third task which does the actual await . On that third task’s :DOWN message check if there are pending events to start the cycle all over again. OK! In this approach I have the feeling of k…

Hello, If you need to await your tasks in your handle_in because you want to avoid race conditions, you must use the “async” family of task functions, to be able to call Task.await afterwise. With a “start” function you would have to send yourself a “done” message, which is ok but it’s simpler to “…

[image] fxn: Oh man, need to develop fluency thinking about this, feel very clumsy! Your first (async/await) version was fine if that’s all that channel/topic is ever going to do - my concerns were based on the expectation that this process could accumulate more and more responsibilities over…

Elixir Programming Language Forum

Task.start vs TaskSupervisor

Questions & Help Questions

fxn November 12, 2019, 2:15pm 12

Deleted a comment, I saw flaws in the questions. I’ll revise.