[LV2] Is state:threadSafeRestore potentially breaking state:loadDefaultState?

[Hanspeter Portner]

Hi list

The state:loadDefaultState feature [1] is really nice as the plugin author needs
to define initial plugin state in one place only (the *.ttl) and host will apply
it directly after instantiation.

lv2:instantiate -> state:restore -> lv2:run

With the introduction of parallelized state:restore with state:threadSafeRestore
feature [2] in conjunction with state:loadDefaultState there's the potential for
an undefined initial plugin state, though.

lv2:instantiate -> state:restore -> work:schedule -> lv2:run -> work:response
                                        |                           |
                                    work:work -----------------------

If plugin's initial state is only set in work:response and the latter is run
only after the first lv2:run (e.g. because work:work is run in its own thread),
state may not be properly defined at first lv2:run.

If the plugin supports state:threadSafeRestore and requires
state:loadDefaultState, work:respond should be called sequentially at instantiation.

lv2:instantiate -> state:restore -> work:schedule -> work:work -> work:response
-> lv2:run

So, I'd like to propose that hosts MUST run state worker in instantiation
threading class at instantiation of plugins requiring state:loadDefaultState
feature (or something else that ensures work:respond to be called before first
lv2:run).

I have not checked host implementations, maybe they do it already that way, but
it's not at all clear in the spec.

Does this make any sense to anybody?

[1] http://lv2plug.in/ns/ext/state#loadDefaultState
[2] http://lv2plug.in/ns/ext/state#threadSafeRestore