[LV2] Worker extension

[Stefan Kersten]

On 3/23/12 2:42 PM, David Robillard wrote:
> 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().

ok, i see.

>> 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.

sure, but there's no reason not to allow plugins provide information 
that can *optionally* be interpreted by the host, is there?

> 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)

call it contexts or priorities, but a way to transmit this information 
to the host would be nice, e.g. as a parameter to `schedule_work'.

<sk>