[LV2] Worker extension
d at drobilla.net
Fri Mar 23 10:20:30 PDT 2012
On Fri, 2012-03-23 at 17:47 +0100, Stefan Kersten wrote:
> On 3/23/12 4:13 PM, David Robillard wrote:
> > To be clear, I don't think priorities are good but unfortunately
> > complicated, I actively think priorities are a bad idea for this.
> that's probably what i meant, different execution contexts.
> i don't see a real functional difference; depending on a context
> (priority) parameter the host can use a different queue + worker thread
> + thread priority, just as with using a different uri to address another
> context. the only real difference is feature detectability as you note
It seems you are simply using "priority" as a synonym for "context".
This is confusing things. A "priority" inherently implies *scheduling*,
and it not equivalent to a context (a thread may have a priority, that
is an entirely different thing to giving each request a priority).
Giving each request a priority means the host would have to take all the
requests sent by plugins, sort them somehow, and execute them in such a
way that lower priority messages never preempt higher priority messages.
While all this is happening, new requests can come in from the next
cycle, possibly with a higher priority than a request being executed
now. This seems to be at a "hard real-time operating system kernel
scheduler" level of difficulty.
If you equate priority to context, then you don't have priorities at
all. A context simply executes things in the order they arrive.
Ringbuffer in, ringbuffer out, for loop. No priorities, no scheduling,
no fancy data structures. Easy.
> > What is an example of a use case for this anyway? I suspect there may
> > be legitimate reason to add *one* more context, but only reluctantly.
> > This is a very slippery slope.
> e.g. in a plugin that streams samples from disk you obviously don't want
> to wait until a long-running non-realtime task has finished.
It would be problematic to have a dramatically long-running anything in
the worker since this could block other plugins as well. We probably
need some rules for this.
More information about the Devel