[LV2] Is state:threadSafeRestore potentially breaking state:loadDefaultState?
ventosus at airpost.net
Sat Dec 31 02:53:31 PST 2016
The state:loadDefaultState feature  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  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
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
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
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?
More information about the Devel