[LV2] Is state:threadSafeRestore potentially breaking state:loadDefaultState?
d at drobilla.net
Wed Jan 4 21:43:45 PST 2017
On Sat, 2016-12-31 at 11:53 +0100, Hanspeter Portner wrote:
> Hi list
> 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
> | |
> 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
> 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...
More information about the Devel