Yes, my earlier statement was a white lie - the issue I linked to describes exactly what you are running into. It is possible to abort HTTP requests using spawn and kill, but not while retaining the ability to get at the result. This is the interprocess communication Evan is talking about. So AFAIK it's not currently possible to do what you're asking.
On Wed, 29 Jun 2016, 17:03 Mark Hamburg, <[email protected]> wrote: > Thanks for correcting the information on whether or not killing works for > HTTP requests. I had thought it did and then seen an assertion to the > contrary earlier in the thread. > > But that then leads to a question of whether anyone has found a good > pattern for making use of cancelation. An update function creates a task > that at present seems interesting but might cease to be interesting before > it returns. To get the results back from the task, it converts it into an > appropriately tagged command and returns it up through the update > hierarchy. But what if we want to be good about canceling work in which we > no longer care about the answer? Now the task needs to go through spawn to > generate a task generating a process id that we can then capture via the > tagged update routing just as we could with the original task result and > having that process id in hand, we can later cancel if we so choose. Great > but now we've lost the opportunity to route the results from the real work > task. In 0.16, we could have included a step to send the results to a > mailbox, but 0.17 doesn't work that way. So, what is the preferred code > pattern to handle this in 0.17? > > Mark > > On Jun 29, 2016, at 12:26 AM, Evan Czaplicki <[email protected]> wrote: > > Process.spawn and Process.kill let you "kill tasks". Killing a process > that has an HTTP request pending will cancel the request as well. > > Interprocess communication is not ready yet, but the current API can cover > some use cases. > > On Tuesday, June 28, 2016, Mark Hamburg <[email protected]> wrote: > >> I would absolutely tag the tasks. You can do this in the response action. >> I recommend keeping a counter in the model and advancing it whenever the >> basis for requests changes. >> >> Aborting would be ideal but it's harder or potentially impossible at >> present. >> >> Mark >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Elm Discuss" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > > > -- > Sent from Gmail Mobile > > -- > You received this message because you are subscribed to the Google Groups > "Elm Discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "Elm Discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
