Skip to content

Conversation

@jenshannoschwalm
Copy link
Collaborator

Following 6d50199. We start the gphoto thread after all job threads are up&running and continue in dt_control_jobs_init() after the photothread is up&running.

@wpferguson this is fixing a second potential cause of race conditions related to back threads.
@TurboGit for me again a safe one.

@jenshannoschwalm jenshannoschwalm added the bugfix pull request fixing a bug label Dec 29, 2025
@jenshannoschwalm jenshannoschwalm added this to the 5.4.1 milestone Dec 29, 2025

dt_control_t *control = darktable.control;
dt_atomic_add_int(&control->running_jobs, 1);
g_usleep(100000); // no haste, keep going in main thread
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd recommend adding another zero to make it a full second, to be extra-sure that we don't accidentally skip the run loop because it took a while for dt_control_running to actually return TRUE. As the comment says, no haste....

@jenshannoschwalm jenshannoschwalm marked this pull request as draft December 30, 2025 15:42
Following 6d50199.
We start the gphoto thread after all job threads are up&running and continue in
`dt_control_jobs_init()` after the photothread is up&running.

Make sure we usleep() also if there is currently no cam_ctrl
@jenshannoschwalm jenshannoschwalm removed this from the 5.4.1 milestone Jan 3, 2026
@jenshannoschwalm jenshannoschwalm removed the bugfix pull request fixing a bug label Jan 3, 2026
@jenshannoschwalm
Copy link
Collaborator Author

Let's see

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants