- 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