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
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
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)
Le 2012-01-22 à 21:16:00, Miller Puckette a écrit :
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.
That's called a newline... not preceded by a backslash. The thing
As it stands right now, there are new-lines in the middle of certain tcl
commands sent from Pd, so if newline were it, I'd have to go chase down all
the pretty-printing newlines in the Pd code and delete them. That might
actually might work; I'd only be worried taht some extern was throwing up
