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