[LV2] worker thread question

hermann meyer brummer- at web.de
Sat Dec 29 22:49:30 PST 2012

Am 30.12.2012 07:02, schrieb hermann meyer:
> Am 30.12.2012 02:37, schrieb Robin Gareus:
>> On 12/29/2012 09:16 PM, hermann meyer wrote:
>>> Am 29.12.2012 20:35, schrieb David Robillard:
>>>> As I said, this was tried, and it was much, much more complex and 
>>>> raises
>>>> a massive set of problems for little to no benefit.  It is 
>>>> particularly
>>>> tedious to implement on the host side, which is why nobody implemented
>>>> it.  Doing I/O in run() is a deliberate design decision arrived at 
>>>> after
>>>> a lot of thought and experimentation.  It is this way for good 
>>>> reasons.
>>>> In short, you're breaking very important rules in order to "optimize"
>>>> away nothing significant, with a result that's much more complicated,
>>>> error prone, and slow than the simple and correct solution.
>>>> This code is broken and needs to be fixed.  Do not break the threading
>>>> rules of the API.  Seriously.
>>>> -dr
>>> sadly I notice that you didn't understand the need of non-rt dsp
>>> processing with user interaction in a plug-in. To bad :-(
>>> I guess that you makes thinks more complicated then they really are.
>>> That isn't what I understand under a Open spec. Your assumptions leads
>>> to no way for implement what I need to make my plugs work with your
>>> bless, so be it. I have tried to find a way for communication about 
>>> that
>>> with you, but it seems to me there isn't.
>> That's what I sometimes like about AU or even VST. There's no
>> discussions about *but we can make it work by hacking and circumventing
>> the spec* or the *spec should be changed*..
> Morning all
> well, I didn't ask for hacking the spec, or change it, it was just my 
> answer to the first reactions on my source. Actual I can make it work 
> with the spec's which are there.
>>> Maybe you tried out my work, before you totally negate it.
>> My thoughts about the watch_thread() are unprintable. That's incorrect
>> plugin design. Accessing 'self->schedule' from this context is just 
>> wrong.
> Could you explain me why? I call a thread from a other thread, so 
> under which circumstances it mater from which thread I call it? If I 
> get what you mean here, I could truly move this call to run, just 
> using a sem_post. But it seems to me foolish to do so.
Ah,:-[ okay, I get this point and will move the schedule call to run.

> I watch port values from a pointer, which is a private member of my 
> class, as well as the thread I use to watch it, as well as the 
> function for run(). So could you explain to me why that could 
> influence the host, when I watch it from a other thread then run()? I 
> didn't need the port values in run(), I just need them in "a worker 
> thread". I could avoid to use the worker at all, and use my own, but I 
> understand from the discussion about the convolver.IR on LAD, that 
> this is wished to be avoid, ad I understand why. For the very same 
> reason I come here and ask for the watch tread approve. It is negated 
> here, okay, but I didn't get a reason for why "I" shouldn’t use it on 
> my own.
> I really like to find a way which satisfy all of us, but just say 
> "that didn't work" or "this is wrong", wouldn't help or lead to a 
> conclusion.
> Again, here in this example, I just check for two ports values, and it 
> already makes a diff in the CPU usage from the rt-thread and the 
> overall CPU usage. When I'm ready with what I have I mind, that could 
> become more then 20. ports which I need to watch. It is clearly to 
> avoid to do that in the rt-context. Again, I never try to write to the 
> mem the pointers point to, even if they point to NULL, it wouldn't 
> harm. So why the hell it should harm a host when I watch them from 
> were ever?
>>> That it works stable, have nothing to do with luck.
>> It certainly is luck. It will probably work in 99.9% of all cases. but
>> certainly not 100%.
> Sorry, please show me a example were it didn't work, even if it is 
> theoretical, . .
>> Otherwise: nice work! I'm looking forward to a gx LV2 plugin. You went
>> to so many troubles to make guitarix outstanding software, why not go
>> the last mile too and make it a proper LV2 plugin?
> I'm just started this experiment.
> we have defined our own plug-in specs for guitarix long ago, we pass 
> the port values even as parameters from the UI to the engine and 
> visa-verse.
> As you may notice I have just release the first LV2 amps from 
> guitarix, well, they are without the watch thread approach, and they 
> are far more simple then what I have in mind.
>> Sure, feel free to curse the specs, anytime :) Yes, they could have been
>> written to make your use-case easier. Yes, they suck. but no: LV2 _does_
>> allow for non-dsp realtime and non-realtime work. ..and it sucks way
>> less than most similar specs. I'm sure you must have cursed at gtk or
>> libx11 or even jack at some point during gx development and solved
>> things properly at that end. Just bite the bullet and include LV2 in
>> that list of /cursed/ frameworks :)
>> 2c,
>> robin
> _______________________________________________
> Devel mailing list
> Devel at lists.lv2plug.in
> http://lists.lv2plug.in/listinfo.cgi/devel-lv2plug.in

More information about the Devel mailing list