[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.


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