[Clam-devel] Consume and Produce considered evil

[Pau Arumi]

Xavier Amatriain wrote:
> (The following refers to my own experience with my system. Please do not
> try this at home ;)
> 
> Have you wondered what happens if you are developing a new Processing
> class and you do something as innocent as forget to call Consume and
> Produce for your ports?
> 
> If you are using Jack, the Jack server becomes unresponsive and you have
> no way around it except for killing it.
> 
> If you are using PortAudio, it is even more fun ;) Your whole computer
> becomes unresponsive and, in my case, I had no way around it except for
> pressing the reset button!! (I could not even kill X although maybe I
> could have logged in from a remote computed, did not try).
> 
> In any case, I think this is very unhealthy. If I understand correctly
> it would not be that hard to detect a deadlock at the FlowControl level.

you are right, it should be detected by an assert. i think there 
is a DEBUG_ASSERT already. could you recompile with release=0 and 
try again?

i think developing in release mode should be advised against in
the doc. because all the run-time asserts are debug-only.


> Another, and possibly better, solution would be to implement this at the
> abstract class level, calling Consume and Produce for all ports from the
> Do() (no arguments) function.

agree. i'll prepare the patch.
however note that calls to Consume and Produce is already done at 
Do() implementation. i think it's just a matter doing it 
externally (i.e. by the flow control) calling sequentially: 
proc.Do() proc.ProduceAndConsume()
what do you think?

of course the reason it was in concrete Do() at the first place 
was to avoid virtual calls. but now i think it was "early
optimization"

btw, i'm working with a static scheduling. i think this will
reduce a lot of overhead.