[LV2] Worker extension

David Robillard d at drobilla.net
Fri Mar 23 06:42:59 PDT 2012


On Fri, 2012-03-23 at 11:46 +0100, Stefan Kersten wrote:
> On 3/23/12 2:52 AM, David Robillard wrote:
[...]
> > I have updated SVN so the eg-sampler plugin uses this instead.  There is
> > one pretty tricky aspect about this extension: if you want to write to
> > an output port as a result of some work (e.g. to notify the UI), you
> > have to do so in a callback other than run().  This means the host must
> > call the response callback *after* run, and can be a bit tricky from the
> > plugin POV.  It also doesn't jive with my opinion that it's is an error
> > for ports to be accessible outside run() at all (though of course this
> > is in the same context).
> 
> execution order of `run' and `work_response' shouldn't matter, right?

The problem is, in work_response() you may want to write to an event
output port.  If so, that port needs to be initialized first.  Therefore
work_response needs to be called after run().

> the only thing i am missing is priorities; e.g. when streaming from 
> disk, those messages could be made higher priority than other 
> non-realtime messages or be actually sent to a higher priority worker 
> thread. maybe the atom/message extension could be used to specify 
> worker/scheduler metadata (like priorities) in an extensible way?

About 99999999 times more complicated than what I intend here, or what I
think it's reasonable to demand hosts implement.  The idea here is to
avoid a billion threads and ringbuffers everywhere, and it can be
implemented with 2 ringbuffers, 1 buffer for the response (which could
be eliminated at the cost of not giving the plugin a pointer to the
response, but a read function instead), and a thread, all of which can
be shared between plugins.

Implementing a scheduler and/or priority queue and some unspecified
number of worker threads is way beyond what it's reasonable to expect
hosts to implement.  Is it really necessary?

Unless it can be decomposed into something very simple, if you need
something that advanced it should probably just be done in the plugin.
The problem to avoid is mainly even basic plugins having to spawn a
bunch of threads and deal with communication and synchronization and
whatnot.

That said, it would perhaps not be so difficult to provide the exact
same interface with different URIs for different contexts.  Maybe there
should be provision for the plugin making its very own worker context,
which is genuinely dedicated to the plugin?  Not priorities though (I
don't think that's actually the right way to achieve this even if it
didn't have anything to do with API)

Thanks,

-dr





More information about the Devel mailing list