<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 2, 2015 at 10:25 AM, Dean Tribble <span dir="ltr"><<a href="mailto:tribble@e-dean.com" target="_blank">tribble@e-dean.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">On Mon, Mar 2, 2015 at 6:32 AM, Gray Zhang <span dir="ltr"><<a href="mailto:otakustay@icloud.com" target="_blank">otakustay@icloud.com</a>></span> wrote:<span class=""><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><p>+1 to the <code>ignore</code> term, I’ve opened an issue about it in <a href="https://github.com/promises-aplus/cancellation-spec/issues/14" target="_blank">https://github.com/promises-aplus/cancellation-spec/issues/14</a></p></div></blockquote></span><div>I have little attachment to any term, but there's value in keeping terminology that has years of investment and use in other contexts. However "ignore" also has the wrong sense, because it implies that the computation completes anyway. That can be accomplished more easily by simply dropping the promise.</div></div></div></blockquote><div><br></div><div>Agree. But I feel even more strongly that "cancel" is the right term and "ignore" the wrong one. In the real world, when I order something to be delivered, if I then decide to "ignore" it, that describes how I react to receiving the package. It is a private decision about how I will react and does *not* communicate any information to the sender about that decision. If I attempt to cancel the order, I may or may not receive the package because of the asynchronous race that Dean describes. But even if I receive the package, it does not violate my encapsulation expectations for the sender to find out that I attempted to cancel.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><p>IMO the term <code>cancel</code>(or <code>abort</code>) and <code>ignore</code> are totally different things, the former one means “do not continue, stop it right now” and the “stop” state should be broadcast to everyone who is interested in the work, while the latter means “I don’t care about the result anymore, just play it as you like”, it means the async progress can be continued</p></div></blockquote></span><div> This goes back to some of the observations above: you cannot stop it "right now" because async notification is not synchronous; indeed the operation may already be complete before you stop it. Thus consumers of the result of a cancellable request need to be able to handle either successful completion or the cancelled state (which just looks like any other error that prevented completion).  Attempting broadcast to "everyone" adds complexity and resources that are needed only in the rare cancellation case. It's typically not only not worth the software complexity, but not a good idea. When you cancel a print job, the document editor should make best efforts in the background to stop requesting fonts, stop laying out print pages, stop spitting out pages on the printer, etc. but most importantly, it should start paying attention to my new edits and hang waiting for everything that might be involved in printing to wrap itself up.</div><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><p>In practice both scenario are commonly seen, we may <code>abort</code> a resource fetch in order to save bandwidth and opened connections, or we may in other side just <code>ignore</code> it since continue to complete the fetch can result in a local cache, which speeds up our fetch next time</p></div></blockquote></span><div>The resource point is important. That's the "don't care" scenario, not the "abort" scenario. It's the request processor that knows what cleanup is worth the effort. The initiator of the request only knows they don't care about the result anymore.</div></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <div class="gmail_signature">  Cheers,<br>  --MarkM</div>
</div></div>