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.

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.
@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....

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

Labels

bugfix pull request fixing a bug

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants