Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Cancel All My Appointments!

Cancel All My Appointments!

(Video: https://www.youtube.com/watch?v=VDaKLQE03ss)

The most complicated state in an application is time. Like cooking a bag of microwave popcorn, modern web applications desperately try to keep up with their state through an orchestrated chaos of asynchronous operations popping off in indeterminate cadence. No question, coordinating all this concurrency is hard.

But there's a pitfall at the heart of asynchrony that stays mostly unaddressed.

When an operation doesn't finish right away, synchronously, it's possible the operation may never finish. Or, it may be destined to finish eventually, but a second operation may be raised which means we no longer care about the first. Whatever the case, we need to be able to cancel it. This critical check ultimately protects users from the vagaries of unpredictable systems.

Cancellation should be core to our async programming; no asynchrony should run without it. Too often, such handling is just a corner case exception. Without a cancellation strategy, your applications are incomplete at best.

We'll discuss use-cases for async cancellation and various approaches to managing them.

Kyle Simpson

December 07, 2018

More Decks by Kyle Simpson

Other Decks in Programming


  1. Cancel All My Appointments! Kyle Simpson @getify

  2. HAPPENS Failure @getify

  3. HAPPENS Cancellation @getify

  4. Cancel Abort Call-Off Abandon Stop Kill Revoke Quit Pause? Terminate

    Undo? @getify
  5. Cancel Abort Call-Off Abandon Stop Kill Revoke Quit Pause? Terminate

    Undo? Final } { Recover
 Rollback Event? State @getify
  6. Events are unexpected. States are expected. Cancellation should never be

    an unexpected exception. Cancellation should be a predictable state. @getify
  7. ? @getify

  8. ¯\_(ϑ)_/¯

  9. ing Problem @getify

  10. How? @getify

  11. Approximate! @getify

  12. Timeouts @getify

  13. Schrödinger's Cat Quantum Superposition @getify

  14. @getify

  15. Schrödinger's Asynchrony @getify

  16. @getify

  17. Cancel...a Cancellation? @getify

  18. @getify

  19. Cancelable Promise? @getify

  20. Wrong Level of Abstraction @getify

  21. Schrödinger's Cancellation @getify

  22. @getify

  23. Cancelable Promise: "Action At A Distance" Unpredictable State Just Say

    No. @getify
  24. Complexity Randomness ~ ~ @getify

  25. UNCERTAINTY @getify

  26. Cancel what? @getify

 USERS . . . . .

  28. @getify

  29. @getify

  30. @getify

  31. @getify

  32. @getify

  33. @getify

  34. @getify

  35. Cancellation Must Be
 A First Class Citizen @getify

  36. Developers, Developers, Developers? @getify

  37. Timers @getify

  38. Ajax Calls @getify

  39. User Events @getify

  40. What about...? @getify

  41. File System Operations @getify

  42. Stream Operations @getify

  43. Network I/O @getify

  44. Database Queries @getify

  45. Child Processes @getify

  46. Yadda, Yadda, Yadda... @getify

  47. @getify

  48. @getify

  49. Debounce: Spinner @getify

  50. Debounce: Spinner @getify

  51. Un-observable-ation Implied Cancellation @getify

  52. Starvation @getify

  53. @getify

  54. https://vorpus.org/blog/timeouts-and- cancellation-for-humans/ @getify

  55. Edge-Triggered vs Level-Triggered Event vs State @getify

  56. @getify

  57. Events can be missed. State isn't. @getify

  58. Event composition can be complex. State transition isn't. @getify

  59. Timeouts vs Deadlines @getify

  60. Timeouts vs Deadlines @getify

  61. Cancellation:
 Serial vs Concurrent @getify

  62. @getify

  63. @getify

  64. ...oops, only Shallow Cancellation @getify

  65. Deep(er) Cancellation @getify

  66. Race: A xor B @getify

  67. @getify

  68. Promises are a bit awkward here @getify

  69. Cancellation Tokens @getify

  70. @getify

  71. cancelable fetch! @getify

  72. Async Functions:
 not (externally) cancelable @getify

  73. @getify

  74. @getify

  75. CAF (Cancelable Async Flows) https://github.com/getify/CAF @getify

  76. @getify

  77. still cancelable fetch! @getify

  78. Tedious? @getify

  79. Idea*:
 Cancellation Zones (*still very rough idea) @getify

  80. @getify

  81. What's missing: atomicity Not just convenience. DB transactions are "easy".

    Atomic cancellation as state is hard. @getify
  82. Cancellation: Abstraction Levels Exception (Uncertainty) Event State Collection of States

  83. If it's async, it's gonna get
 canceled finally { ...whether

    you handle that state or not. cancellation shouldn't be an unexpected exception. @getify
  84. unexpected cancellation states feed uncertainty. } uncertainty spreads unnecessary complexity.

    complexity cancels out software quality and momentum. @getify