[LV2] worker thread question

[David Robillard]

On Sat, 2012-12-29 at 08:55 +0100, hermann meyer wrote:
> Am 29.12.2012 05:22, schrieb hermann meyer:
> > Am 28.12.2012 23:59, schrieb David Robillard:
> >> More threads, more problems.  Do non-rt things in a worker, and I/O and
> >> processing in run().  More threads complicated things massively for no
> >> win.  The idea of a "watch thread" doesn't really make any sense.
> > Thanks for taking you time
> >
> > bye
> > hermann
> 
> So I have add my own watch thread, for the case you like to review the 
> source, here it is:
> 
> http://sourceforge.net/p/guitarix/git/ci/11f2c1985e4c553ccd66b5fce2acd0a760923b49/tree/trunk/src/LV2/gxamp.lv2/gxamp.cpp
> 
> I have just 2 float values to check here, so it wouldn't spare much 
> processing, but as I said, that will properly change in the next time.

Oh my.  Bloat aside, this code is very broken.

You can not call schedule_work from any thread.  It MUST be called from
the run() context, and ONLY the run() context.

Once again, the entire point of the worker is to schedule non-RT work
from run().  If you aren't going to do that, then just don't use it.

You also seem to be reading port buffers from another thread?!  You can
not access port buffers from any context but run().  Since there is no
port lock or anything like that it should be obvious that this can't be
thread-safe.  This seems to be the main source of all your confusion:
ports are accessed in run(), and ONLY from run().  This is true for
control ports, audio ports, MIDI, and messages as used by the
eg-sampler.  It is a deliberate design decision.  If you want to compare
port values in another thread, then you will have to transport the
values to that other thread somehow (e.g. via a ringbuffer which is how
the worker is implemented).  This is why you won't speed anything up
that way.

Please do not release plugin code that violates the threading rules in
the API.  It will cause nasty errors and/or crashes by violating the
assumptions used in the host implementation.  schedule_work is real-time
safe, but it is definitely NOT thread safe.  You may not access port
buffers in any context but run()[1]

Use your own threads if you like, which sometimes is necessary, but
don't violate the threading restrictions of the API.

-dr

[1] It is a mistake inherited from LADSPA that it is even possible to do
this.  Passing the buffers as a parameter to run() ala VST is better.
-------------- 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/20121229/7aeb2303/attachment-0002.pgp>