Re: Cancellation architectural observations

On Mon, Mar 2, 2015 at 10:25 AM, Dean Tribble <tribble@e-dean.com> wrote:

> On Mon, Mar 2, 2015 at 6:32 AM, Gray Zhang <otakustay@icloud.com> wrote:
>
>> +1 to the ignore term, I’ve opened an issue about it in
>> https://github.com/promises-aplus/cancellation-spec/issues/14
>>
> 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.
>

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.


IMO the term cancel(or abort) and ignore 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
>>
>  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.
>
>> In practice both scenario are commonly seen, we may abort a resource
>> fetch in order to save bandwidth and opened connections, or we may in other
>> side just ignore it since continue to complete the fetch can result in a
>> local cache, which speeds up our fetch next time
>>
> 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.
>



-- 
  Cheers,
  --MarkM