mirror of
https://github.com/hrydgard/ppsspp.git
synced 2026-09-22 04:16:22 +02:00
Henrik Rydgård
b120f0004f
Cancel() worked on the plain HTTP path - cancelled_ is threaded down as progress->cancelled and checked while connecting and reading - but on the naett path it only set a flag that nothing looked at. The transfer ran to completion and cancelling just relabelled the result afterwards. Cancelling a store icon that scrolled away, or a homebrew download the user gave up on, kept using the bandwidth either way. naett has one hook for this: a body writer that takes less than it was given fails the request. So HTTPSRequest installs its own writer, which refuses everything once cancelled. That works on all four backends and needs nothing from naettClose, which is only really safe on Android. The catch is lifetime. The writer runs on naett's transfer thread, and a request that's still going when we're torn down would then be writing into a destroyed HTTPSRequest - which is why the buffer it writes into is a separate refcounted sink rather than a member. Join() on an unfinished request parks the sink where it won't be freed and lets the request go, so a chunk that lands afterwards writes somewhere that still exists. That path is shutdown-only: RequestManager only cancels from its destructor, and Update() waits for Done() before joining. Join now also notices a request that finished while nobody was polling, and closes it properly instead of abandoning it. What's left leaking at that point is a request still in flight as the process exits, which is what already happened, just deliberate now and logged as such rather than as an error.