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

[David Robillard]

On Sat, 2016-12-31 at 11:53 +0100, Hanspeter Portner wrote:
> 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?

It seems silly for a host to do this at all for initial state since the
plugin isn't even activated yet anyway, but I suppose that requires
plugins to support loading state either way.

Though this is not a bad idea for backwards compatibility anyway...

-- 
dr