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.
