I3.12.3reorder and cancel background tasks设计
用户应能对已提交的后台任务重新排序或取消而非只能等待
别名: 取消后台任务 · 重排队列 · cancel job · 不只是等
概念解释
任务已经交出去，人的优先级却会变：这张图要先发、那份备份可以不要了、点错的转码应立刻停。可重排或可取消让已提交的工作仍受人手动覆盖，而不是交出去就只能等执行器按自己的节奏跑完。不能覆盖的队列把人锁在一份过时的计划里。
这和等待过程中的取消不是同一层：那里谈的是当前这次加载能不能中止。这里谈的是已经作为对象存在的后台件，在队列里的位置和生死。列表作为表面可以没有手动排序；一旦有多件且耗时长，没有覆盖就等于调度的默认不可纠正。
机制
提交是对未来资源的预约。预约之后世界会变：对话变得更急、发现选错了文件、电量告急。执行器不知道这些，除非人能改预约。重排改的是相对顺序，取消改的是预约是否还在。两者都要作用到真实执行，而不是只改列表上的行序：取消必须停下正在跑的那件并释放带宽，重排必须让新的第一件真正获得资源。只改显示的队列是第二层谎言。
取消还留下处置问题：已完成的那一段怎么办。部分上传、部分转码，取消后应说明丢掉还是保留半成品。不说明，人会以为「取消等于撤销一切」，或以为「已经上去的那截还在」。重排若把正在跑的一件挤下去，那一件应回到可续的断点，而不是被取消。
边界
不可中断的硬操作（某些固件写入、支付清算一旦开始）可以拒绝取消，但要在提交前说清，并在列表里标成不可取消，而不是按钮点了没反应。别人提交、你只是旁观的共享任务，取消权跟身份走。系统为你自动提交的维护任务应可取消或推迟，否则「用户应能」不成立。单件且正在前台、几秒就结束的，重排无对象可排；取消仍应在。误触取消的代价若接近毁掉长时间劳动，确认要明确，或提供短窗口的撤销取消。
怎么落地
- 每件未完成任务提供取消；多件时提供改顺序（拖动或「提到最前」）。
- 取消作用到执行器：带宽和 CPU 应在数秒内让出。已完成部分的命运写在确认里。
- 被挤下去的任务保持断点，不当成取消。
- 验证：排队三件，把最后一件提到最前，观察它是否开始占用资源、原来正在跑的是否暂停并可续。取消中间一件：它应从列表的进行中消失，且网络活动下降；已写出的半文件要么被清要么被标明保留。点一个标成不可取消的固件任务：提交前应已告知，按钮应不可用而不是点了假装取消。