Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Ansel freezes by applying style from the darkroom #262

Closed
lologor opened this issue Dec 8, 2023 · 2 comments
Closed

Ansel freezes by applying style from the darkroom #262

lologor opened this issue Dec 8, 2023 · 2 comments
Labels
bug priority: high Affects basic and core functionnalities of the software in a way that severly degrades usability

Comments

@lologor
Copy link

lologor commented Dec 8, 2023

Description of the bug

Ansel freezes by applying style from the darkroom.

To Reproduce

  1. Open picture in darkroom
  2. Apply style
  3. Ansel is frozen

Expected behavior

Style is applied and ansel continues to work
Screenshots
Bildschirmfoto 2023-12-08 um 22 26 02

Which commit introduced the error

Version compiled based on commits of wed. 6/12 (22:00) works.

System

  • Ansel version : 6083b54
  • OS : OSx (13.6.1)
  • Memory : 16 GB
  • Graphics card : M2 Pro
  • Graphics driver :
  • OpenCL installed : yes
  • OpenCL activated : yes
  • Xorg :
  • Desktop :
  • GTK+ : 3.24.38_1
  • gcc : Apple clang version 15.0.0 (clang-1500.0.40.1)
  • cflags :
  • CMAKE_BUILD_TYPE : Release
@pedrorrodriguez pedrorrodriguez added bug priority: high Affects basic and core functionnalities of the software in a way that severly degrades usability labels Dec 9, 2023
@aurelienpierre aurelienpierre mentioned this issue Dec 12, 2023
Closed
@aurelienpierre aurelienpierre mentioned this issue Jan 2, 2024
Closed
@beudbeud
Copy link

beudbeud commented Jul 5, 2024

any update about this issue? I tried last appimage and i have same problem

@aurelienpierre
Copy link
Collaborator

No news, the solution is to write an high-level image manager to handle global mutex locks.

aurelienpierre added a commit that referenced this issue Jan 9, 2025
@aurelienpierre
Pipe threads locks: remove redundant locks, change the logic
17ffeed 
- Remove dev->pipe_mutex (shared between pipes) that was redundant wich a much older pipe->busy_mutex lock.
- Remove pipe->busy_mutex locks from internal functions and protect top-most functions, aka pipeline jobs.

So, from there we have 3 locks:

- dt_mimap_cache_lock/release, which captures an app-global lock to protect access to image buffer (input), from disk or memory cache
- dev->history_mutex, which captures a dev-centric lock to protect history manipulations from/to the development stack
- pipe->busy_mutex, which captures a pipe-centric lock to protect the pipeline nodes topology.

Remains to implement an app-wise DB lock to ensure only  one part of the soft can access DB histories at the same time.

Partial fix for #262
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug priority: high Affects basic and core functionnalities of the software in a way that severly degrades usability
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@beudbeud @aurelienpierre @lologor @pedrorrodriguez