Processing loops are back again, but different

[wpferguson]

Last processed on 3/1 with no looping activity.

Today processing I got a loop when doing rotate and perspective. Image didn't rotate, so went back out to lighttable and back in to make it update.

A few images later I got the flashing "working" that indicates a loop, but I did a crop and it worked and the image updated. Had to go to lighttable and back to darkroom to get the "working" to stop.

I'll try a bisect.

@jenshannoschwalm

[wpferguson]

bisect is

ca34bce11fe3fae88f435c2033002b7f94efd08b is the first bad commit
commit ca34bce11fe3fae88f435c2033002b7f94efd08b
Author: Hanno Schwalm <hanno@schwalm-bremen.de>
Date:   Wed Mar 5 12:04:15 2025 +0100

    Pipe shutdown maintenance and performance
    
    Pixelpipe fast shutdown via the atomic pipe->shutdown now has `dt_dev_pixelpipe_stopper_t` for readability and
    possibly tracking down issues due to pipe shutdown.
    
    One example was the "spurious shutdown" check leading to endless pipe looping due to an unchecked race condition,
    this check now gives more precise log info.
    
    As we now support pipe shutdowns due to module-internal errors or requests to re-run the pipe (the first example
    is the haze removal module now calculating ambient light and distance from full image data for more consistent output
    compared with exports.
    In all those situations we assume that cachelines for later modules are not valid any more,
    we pass the iop_order of the stopping module so the cache can be cleaned.
    
    While being here:
    - avoid some time consuming actions like pfm writing or benchmarks if the pipe has a shutdown flag.

 src/develop/develop.c      |  8 +++++--
 src/develop/pixelpipe_hb.c | 57 ++++++++++++++++++++++++++++++++--------------
 src/develop/pixelpipe_hb.h | 17 +++++++++++++-
 src/iop/hazeremoval.c      |  8 +++----
 src/views/darkroom.c       |  4 ++--
 5 files changed, 67 insertions(+), 27 deletions(-)

I'll try running with -d pipe and see if that yields any further info.

[wpferguson]

Can't reproduce using -d pipe. The logging must change the timing just enough. I'll try again later.

[jenshannoschwalm]

@wpferguson i think i might know now where "things happen".
Could you in dt_dev_pixelpipe_cleanup_nodes() move the dt_atomic_set_int(&pipe->shutdown... after the dt_pthread_mutex_lock(&pipe->busy_mutex) ?

[wpferguson]

Did the change and processed 70 images without a hiccup.

[jenshannoschwalm]

Unfortunately that's for sure not the right way as it's breaking the pipe shutdown. We will have to add test&clear the shutdown flag. I will later do a proposal.