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
_______________________________________________
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
