[BUG] Heavy decoding permanently stops after fast scrolling (HeavyLanePool IO semaphore leak on cancellation)

[Huangzhiqiang]

Describe the bug

When rapidly scrolling / flipping through images (faster than the prefetch/cache can handle), the app correctly stops decoding images that are no longer visible — this is expected behavior.

However, after stopping the fast scrolling and then trying to view any new image (even slowly), decoding never resumes. The image remains blank / white / unloaded forever until the application is restarted. This effectively deadlocks the heavy decoding pipeline.

To Reproduce

1. Open QuickView with a folder containing large / heavy images (e.g. JXL).
2. Scroll / arrow-key / mouse-wheel very quickly through 20–50+ images in rapid succession (faster than ~100–200 ms per image).
3. Stop scrolling and try to view any single image slowly (wait 5–10 seconds or more).
4. Observed: No decoding starts — image stays unloaded. Worker threads appear stuck / no CPU/disk activity for heavy decoding.
5. Only way to recover: restart the application.

Expected behavior

After fast scrolling stops, decoding of the current (and prefetched) images should resume normally within a short time.

Suspected root cause

From reading the code around commit 57ebfd7 (HeavyLanePool logic):

• HeavyLanePool uses a std::counting_semaphore (m_ioSemaphore) to limit concurrent IO / heavy decoding operations.
• When fast navigation happens, CancelOthers() (or similar) calls request_stop() on busy workers / tasks.
• However, workers that acquired the semaphore via .acquire() before being cancelled do not release it on stop.
• This causes the semaphore count to leak downward permanently → eventually reaches 0 and never recovers.
• New tasks submitted after stopping cannot acquire the semaphore → decoding pipeline is deadlocked.

(Note: This analysis / diagnosis was generated with the assistance of Grok AI based on the described symptoms and typical patterns in the provided commit / class name.)

Suggested fix

Add RAII-based automatic release of the IO semaphore in the worker loop.

Example minimal patch concept:

// In HeavyLanePool (private helper)
struct ScopedIOSlot {
    std::counting_semaphore<...>& sem;
    bool acquired = false;
    explicit ScopedIOSlot(auto& s) : sem(s) { acquired = sem.try_acquire(); /* or .acquire() */ }
    ~ScopedIOSlot() { if (acquired) sem.release(); }
};

// In WorkerLoop, around the decoding section:
{
    ScopedIOSlot slot(m_ioSemaphore);
    if (!slot.acquired) continue;  // or wait/retry logic

    // ... actual heavy decode work ...
}  // ← auto release here, even on early return / exception / stop

[justnullname]

QuickView_v4.2.6.zip

Hi @Huangzhiqiang ,

I wasn't able to reproduce this bug locally, but I've reinforced the HeavyLanePool logic and implemented a potential fix for the semaphore leak. I have attached a test version (QuickView_v4.2.6.zip) below.

Could you please test this build and see if the issue still persists? Your feedback would be very helpful.

[Huangzhiqiang]

After applying the fix in commit c6b1446 ("fix: resolved HeavyLanePool deadlock during fast navigation (Bug #85)"), the permanent deadlock is improved but not fully resolved.

When rapidly scrolling through images (faster than prefetch/cache), decoding stops as expected.
However, after stopping, new images still fail to decode (remain blank/white) until the app is restarted. The heavy decoding pipeline gets stuck again under high-speed navigation.

Reproduction steps

1. Use a folder with many 5K resolution JXL files (losslessly converted from JPEG, ~6-12 MB each).
2. Scroll extremely fast using mouse wheel, holding right arrow key, or rapid PageDown (faster than ~100–150 ms per image).
3. Stop scrolling and wait on any single image.
4. Result: No decoding starts — no CPU/disk activity for heavy lane, image stays unloaded.
   Only restart recovers it.

Tested environments (same behavior on both)

• System 1: ultra 275HX + 80 GB RAM (high-core, high-memory)
• System 2: i7-11320H + 16 GB RAM (laptop, lower memory)
• OS: Windows 11 (latest)
• QuickView: commit c6b1446 (test build provided by author)

Important observation

• The bug reproduces reliably with the above 5K lossless JXL files.
• When I convert the same images to lossy AVIF (much smaller file size), the bug disappears completely — fast scrolling + stopping works fine, decoding resumes normally.

This strongly suggests the issue is related to longer decoding time / higher IO or CPU cost of JXL vs AVIF, which makes the cancellation window larger and more likely to hit the semaphore leak edge case.

Analysis of the c6b1446 fix

The ScopedIOSlot RAII is a solid improvement and correctly handles release in the tile job path inside WorkerLoop.
However, the deadlock can still occur because:

1. ScopedIOSlot is only applied in the tile decoding path (WorkerLoop). Main full-image decoding (Submit / non-tile heavy jobs, especially first decode of large JXL) may still leak the semaphore on fast cancellation.
2. No conservative extra m_ioSemaphore.release() in CancelOthers() / CancelAll() for workers that are stopped before they acquire the ScopedIOSlot.
3. When reducing IO limit during fast navigation, the try_acquire() loop in UpdateIOLimit() can cause the atomic m_ioLimit and actual semaphore count to drift under heavy contention.
4. TitanMode path skips the semaphore (which is fine), but normal JXL path (long decode + high memory pressure on 5K images) still hits the incomplete protection.

Expected behavior

After fast scrolling stops, heavy decoding should reliably resume for the current and prefetched images, regardless of image format or scrolling speed.

Suggested additional fixes

• Apply ScopedIOSlot (or equivalent RAII) to all heavy decoding submission paths, not just tile jobs.
• Add a safe extra m_ioSemaphore.release() in the cancellation functions (CancelOthers, CancelAll) for each busy worker being stopped.
• Improve UpdateIOLimit to better synchronize limit and actual semaphore count (perhaps release excess or reset when needed).
• Consider a short “grace period” or sticky task for the currently visible image to reduce aggressive cancellation on JXL/AVIF.

These changes should preserve the excellent fast-scroll responsiveness while eliminating the remaining deadlock.

Additional context

Thank you for the quick response and the test build — the ScopedIOSlot change already helped a lot. Looking forward to a more complete fix!

(Note: The diagnosis above was generated with assistance from Grok AI (by xAI), based on reproduction steps, system details, image characteristics, and analysis of the c6b1446 diff.)

---

Environment summary for easy reference:

• Images: 5K lossless JXL (converted from JPEG)
• Systems tested: 275HX+80GB and 11320H+16GB
• Trigger: Very fast scrolling → stop → no resume
• AVIF (lossy, smaller): No bug