As I see it, the only way that [packOSC] can receive a message before it has completed the previous message is if its own output triggers another message to its input. It may be possible to detect that special case and either let it happen or not, but it's tricky because the buffer for the list is deallocated as soon as the list is output, and the new message arrives while that is taking place. Possibly using a fixed buffer would work better, and also speed up the code. The function then might just exit before it is called again, avoiding the error.
Martin On Thu, Nov 5, 2015 at 1:21 PM, Roman Haefeli <reduz...@gmail.com> wrote: > On Thu, 2015-11-05 at 11:11 -0500, Martin Peach wrote: > > > > > In your patch, if you put a [delay] after the bang outlet it will > > start an infinite loop at the delay interval. I'm not sure why the > > delay is necessary though, as [packOSC] should have finished > > processing the previous message by the time the next one arrives, even > > if it's a zero logical time delay. > > Attached patch illustrates that you can simply buffer the output of > [packOSC] with [list append]. This fixes the reentrancy problem > _without_ affecting the execution order. A zero logical time delay > breaks the depth-first rule. > > Roman > > > _______________________________________________ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > >
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list