Set darktable.control after initializing dt_control_t

[jenshannoschwalm]

We don't want the global control struct to be exposed before all internal stuff like mutexes has been set up.

[jenshannoschwalm]

@TurboGit

1. I don't think there is a reality chance for a race condition because of setting darktable.control too early but still correct and safe
2. As we don't really know yet if the gtk main loop is even reached we might want to know that for debugging

[dterrahe]

First of all, obviously this doesn't hurt. But I'd argue if something is trying to use control at this early stage that is a bug. We should not just prevent it from accessing it, we should fix the order things are initialised. Because all of this is being set up in the main thread so there shouldn't be any concurrency yet.

So if in dt_control_running we find that darktable.control == NULL that should be reported as an error and fixed. If need be, dt_control_init can be moved earlier in dt_init. So making this more "robust" means papering over bugs and thereby making it harder to find and fix them.

Agree/disagree?

EDIT: is there an active bug that this fixes? It may still benefit from a better fix?

[jenshannoschwalm]

Agree/disagree?

I (generally) think, if an allocated struct is made public, that should be done after initializing that struct.

But:

1. Agreed, a bug should be fixed elsewhere.

2. Agreed, there is no bug - i am aware of - "fixed" by this

[jenshannoschwalm]

@dterrahe "drafted" but added more code trying to locate a problem in dt_control_running. Here still not a single reproducer ...

[dterrahe]

What we often do when we want a function to print more debug info (and what imho is better) is to make it a macro that calls an "internal" function variant _with_caller and passes it __FUNCTION__ (and possibly also __FILE__ and __LINE__). This is more flexible, faster to use, guaranteed to be "in synce" with any naming changes and doesn't require any further changes besides the header and function implementation.

[wpferguson]

__FUNCTION__, __FILE__, and __LINE__ are already defined somewhere because I use them in fprintf statements when debugging...

[dterrahe]

They're builtins.

What I meant is, #define dt_control_running dt_control_running_with_caller (__FUNCTION__, __FILE__, __LINE__)

[jenshannoschwalm]

Yeah, stupid me not doing that :-) force-pushed updated code with macro-reporting and some cleanup.