[LV2] worker thread question

hermann meyer brummer- at web.de
Sun Dec 30 03:10:46 PST 2012

Am 30.12.2012 11:20, schrieb hermann meyer:
> Am 30.12.2012 09:16, schrieb Robin Gareus:
>> On 12/30/2012 08:43 AM, hermann meyer wrote:
>>> Thanks Robin, for your input, what is open now for me is that I
>>> need to read the port values in the worker thread, and that I would
>>> watch them "outside" from run(). From what I understand about
>>> glib-threads there is no problem as long I only read the values
>>> were my pointers point to (data).
>> I'm not aware of the spec mandating specific behavior of port values for
>> the host-side implementation of the worker thread. Dave?
>> You can access the instance LV2_Handle in the worker thread and
>> you can also use the user-data field to pass information along to it.
>> Since you likely have a local copy of the port data anyway (to compare
>> if value_changed()) it's safer to use that local copy from your
>> instance. Opposed to the data pointed to by ports, you are in control
>> of that variable.
> But those copy is set by use a other thread then run() to get the port 
> value.
> In fact it is set by the worker thread at the end of schedule.
> So the outstanding question is, why should it be un-save to  (only) 
> read the value my pointer points to, from a other thread then run() ?
> greets
> hermann
>> AFAICT The port values themselves may or may not be valid and/or point
>> to new or old data depending on the host implementation while the worker
>> runs.
>> 2c,
>> robin

Okay, so I've moved the port(data) read as well into run() and use my 
internal copy in my watch tread as well in the process in the worker 
thread now. So no more data fields from the host will be used in a other 
context then run() (well init and connect, . . . )
I hope I could solved now all possible violations mentioned here.
If you like to review the latest changes, the source is here:


More information about the Devel mailing list