- From: Jake Archibald <notifications@github.com>
- Date: Fri, 09 Jun 2017 02:20:14 -0700
- To: whatwg/fetch <fetch@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
Received on Friday, 9 June 2017 09:20:59 UTC
> Hmm, that doesn't seem to work so great. I'd expect reading a chunk or transmitting bs to be interruptible, whereas that doesn't seem possible with that spec.
I'm trying to avoid hand-waving cancelation. Maybe we could use language like:
1. Do some work that we can't really abort during.
1. Let *abortSteps* be the following sub steps:
1. Cancel the stream etc etc
1. Abort these steps (would this cancel the whole algorithm?)
1. If signal's abort flag is set, run *abortSteps*.
1. Add *abortSteps* to signal's abort steps.
1. Do some work
1. Do some work
1. Do some work
1. Remove *abortSteps* from signal's abort steps.
1. Do some work that we can't really abort during.
> Maybe we could start by listing all the places you anticipate being able to abort?
That's fair. I'll change my branch to add `Issue:` statements at meaningful abort points.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/pull/523#issuecomment-307340150
Received on Friday, 9 June 2017 09:20:59 UTC