[PD-dev] broken msgs cause Tcl traces, how to debug it?

[Miller Puckette]

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