[PD-dev] broken msgs cause Tcl traces, how to debug it?
Miller Puckette
msp at ucsd.edu
Mon Jan 23 06:16:51 CET 2012
Quick guess; the socket itself (at the OS level) has a fixed buffer size
and if the sending process exceeds it it is suspended until the receiving
process eats at least some of it. The receiving process is thus handed a
truncated buffer.
There's not much way around this. One possibility (if indeed this is a
serious efficiency issue) would be for Pd to append a "done" message to
each batch up tcl to up-send. On the receiving end you could then
just 'string search' to the last occurrence of the special string and
send that text safely to the interpreter.
cheers
M
On Sun, Jan 22, 2012 at 11:42:01PM -0500, Hans-Christoph Steiner wrote:
>
> I've been trying to debug this really annoying issue. The [info
> complete] look in pd_readsocket was causing some drastic slowdowns on
> some GUI objects like Scope~, making them unusable. If you remove the
> [info complete] bracket from pd_readsocket, there are these intermittent
> Tcl stacktraces causes by messages from 'pd' to 'pd-gui' that get split
> in the wrong spot.
>
> I have found one very interesting result: the break always happens at
> 48k. At least when I test with the bitmap-madness.pd patch that comes
> with tclpd. It is a good test patch because it causes heavy pd -->
> pd-gui traffic. So I've tried a bunch of things and not much really
> seems to affect it:
>
> - in configure_socket, change fconfigure -buffering to "line"
> - in configure_socket, add -buffersize 500000 to fconfigure
> - in s_inter.c set GUI_ALLOCCHUNK anywhere from 1k to 64k
>
> It seemed that lowering GUI_ALLOCCHUNK did make it happen more often,
> but always the break was exactly at 48k.
>
> Anyone have any ideas?
>
> .hc
>
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev
More information about the Pd-dev
mailing list