[LV2] worker thread question

[David Robillard]

On Fri, 2012-12-28 at 05:25 +0100, hermann meyer wrote:
[...]
> . . but you will imagine that the design from the eg-sampler example 
> plugin is exactly were I'm talking about (and is what I'm tried first) . 
> The UI send a message to run() which in-turn fire up a worker thread. 
> The internal UI from the host didn't know about that and will not work. 
> So, the internal host UI is brocken.

You seem confused.  The UI, again, has nothing to do with the worker,
everything about that is on the plugin side.  The same message sent by a
host UI would, of course, do the exact same thing, because... it's the
same message.

Also, it's unlikely a host would implement the worker by launching a
thread for every request.  There's just one worker thread.  Possibly
just one for many plugins, even.

The UI of the eg-sampler is a silly thing because most host UIs
currently don't understand how to send such messages.  Hopefully that
will change.  Is this what you mean?  That is unrelated to the worker
though.

There is nothing in the plugin interface about threads, there is no
distinguishing between messages that will be processed in real-time and
those that will not.  This is probably a good thing.
 
> Now I have some controllers which presented to the user as simple knobs, 
> like all other controllers as well, but those knobs control some 
> convolvers which need a impdata.update when the controller is moved.
> Clearly that is a job for the worker-thread.
> For the record,I have no problem to get it all work, that isn't what I'm 
> ask about, my question is related to the UI->host->engine communication, 
> which seems to me, break the internal host UI.

Can you explain what you think is "broken" about host UIs?

As I said, you are confusing yourself by thinking about UIs.  Make the
plugin work.  UIs just control plugins via ports.  There is nothing
special about changes that come from a UI or changes that come from
anywhere else.  This is deliberate, and a good thing.

> A way to handle this issue is to watch the state of those convolver 
> controllers (in the engine) and fire a work thread when needed. This way 
> the internal UI from the host work as well.

Sure.  You can send send tasks to the worker from run() whenever you
want for whatever reason.

> Best way to handle this would be a watch thread (in the engine space) 
> were (controller) state changes could be fetched.
> Imagine that it could come to plug-ins which need to watch a couple of 
> states, and it isn't nice by design to watch them in the rt-thread.

Yes it is.  Those changes, by definition, happen in the RT-thread.  It
would be an awful design to have a whole other thread just to watch for
changes that arrive in run() anyway.

Sending messages to the worker is very cheap.  The entire point of the
extension is to queue non real-time work from run().  That is what you
want to do, it is not a bad design, it is the intended and only purpose
of the worker extension and it works well.

The key thing to realize is that *all plugin I/O happens in run()*.

The alternative is very, very unpleasant.  Trust me, it existed before I
designed the worker, and it's a total nightmare to have multiple
contexts of I/O associated with different ports or APIs or whatever.
This way, everything enters/leaves ports in run(), it's synchronous and
simple, and if the plugin wants to queue off work to another thread, it
is free to do so, but it doesn't complicate the interface of the plugin.
It just works with ports and run() like every other LV2 plugin.

I think you are making this much more complicated than it needs to be.
Your plugin interface is your plugin interface.  Using the worker is
purely an internal matter to the plugin.

-dr
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.lv2plug.in/pipermail/devel-lv2plug.in/attachments/20121228/ad21ba82/attachment-0002.pgp>