Hi Oliy, I really appreciate your input since I'm totally new to writing asynchronous tasks. If I understand you correctly, promises are a better way to go if only one value is collected from S2 by S1. However, S1 will keep polling S2 (once every 1.5 secs, by S2's API specification) for updates on the status of the task that S2 is running. The task can be in several different states and S1 needs to know the current state of the task and pass it on to the client. So, actually, multiple and different values will be sent down the channel. The polling will quit once the task has been completed or timed out (ca 5 minutes). That's why I went for core.async as it seems to be suitable for launching a separate "thread" that takes care of the polling.
Does this make any sense as a rationale for using core.async? Thanks! Brjánn On 13 May 2018 at 20:58, Oliver Hine <oliyh...@gmail.com> wrote: > Hi, > > Not a direct answer, but something that may help you simplify your problem: > > I have a general rule to avoid core.async when only one value would ever > be sent down the channel. For these use cases promises are an order of > magnitude simpler, giving you control of the thread of operation, simple > testing for completion (future-done?), simple timeouts, and no cleanup > required afterwards. > > From what I understand, a promise would fit your requirements and I think > would be much easier to reason about. > > Hope this helps, > Oliy > > > On Tuesday, 8 May 2018 21:45:00 UTC+1, Brjánn Ljótsson wrote: >> >> Hi! >> >> I'm writing a server-side (S1) function that initiates an action on >> another server (S2) and regularly checks if the action has finished >> (failed/completed). It should also be possible for a client to ask S1 for >> the status of the action performed by S2. >> >> My idea is to create an uid on S1 that represents the action and the uid >> is returned to the client. S1 then asynchronously polls S2 for action >> status and updates an atom with the uid as key and status as value. The >> client can then request the status of the uid from S1. Below is a link to >> my proof of concept code (without any code for the client requests or >> timeout guards) - and it is my first try at writing code using core.async. >> >> https://gist.github.com/brjann/d80f1709b3c17ef10a4fc89ae693927f >> >> The code can be tested with for example (start-poll) or (repeatedly 10 >> start-poll) to test the behavior when multiple requests are made. >> >> The code seems to work, but is it a correct use of core.async? One thing >> I'm wondering is if the init-request and poll functions should use threads >> instead of go-blocks, since the http requests may take a few hundred >> milliseconds and many different requests (with different uids) could be >> made simultaneously. I've read that "long-running" tasks should not be put >> in go blocks. I haven't figured out how to use threads though. >> >> I would be thankful for any input! >> >> Best wishes, >> Brjánn Ljótsson >> > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
