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

[Hans-Christoph Steiner]

On Jan 23, 2012, at 12:41 AM, Mathieu Bouchard wrote:

> Le 2012-01-22 à 21:16:00, Miller Puckette a écrit :
> 
>> 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.
> 
> AFAIK, that's 4k or 8k for «unix» type (pipe or fs socket) and it might be 32k for TCP sockets. But code must not rely on specific buffer sizes.

>>> 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.
> 
> yes, [info complete] is a potential major slowdown because it may reparse code many times while the amount of code increases. It's a n² time order thing.

The [info complete] loop had the advantage of actually fixing this problem. The problem wasn't so much just using [info complete] but the condition used to trigger the check.  What was happening was that Scope~ was sending some kind of blank lines a lot, and the "while {![info complete]}" looped fast over these blank lines trying to make Tcl code out of them, eating up a lot of CPU.  I figured I might as well try to solve the underlying problem rather than tacking on workaround on top of workaround.

.hc

----------------------------------------------------------------------------

I hate it when they say, "He gave his life for his country."  Nobody gives their life for anything.  We steal the lives of these kids.  -Admiral Gene LeRocque