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

[Mathieu Bouchard]

Le 2012-01-23 à 13:31:00, Hans-Christoph Steiner a écrit :
> The problem isn't related to sys_gui not enforcing full Tcl commands 
> since the breaks don't happen along the lines of sys_gui command 
> contents.

I know that sys_gui doesn't enforce it, but that's not what I'm trying to 
say. I'm saying that it would be good if sys_gui could send extra data 
such as \0 terminators or size-of-upcoming command so that you don't need 
to run [info complete] at all in the tcl process.

A TCP connection doesn't have actual breaks. This means that if you want 
breaks, you have to add them. Currently, the breaks have to be guessed by 
a combination of parsing and supposing that the OS's breaks will 
eventually match an end-of-statement before the RAM starts swapping or 
before the CPU goes quadratic. That's why I'm thinking about less implicit 
ways of ending statements.

> The only time I've seen a problem is when the commands are broken in the 
> middle of a sys_gui post.

And there are several ways to fix that, and I was speculating about one 
that we aren't usually thinking about, but that might save the effort of 
running [info complete] multiple times on the same data and any other 
kludges we have to combine it with so that [info complete] does the job, 
and other funny side-effects of an [info complete]-based strategy...

> the funny little detail is that when it breaks in the middle of a Tcl 
> command, it is always exactly at the 48kb mark. exactly.

This most probably has to do with the size of the buffers in the TCP 
lasagna of the Linux kernel or OSX kernel. Each OS has its own sizes, and 
in some of them, it's tunable, if you know how (either by playing with 
/proc or /sys, or by recompiling something with a modified config.h, if 
you're not lucky).

A direct pipe (the pipe() command, no port number ; or a /tmp socket-file) 
has usually a different buffer size, iirc. In any case, you can't really 
rely on the buffer size being anything in particular, but the way it is 
now, it may affect Pd, especially in certain tough situations.

> Some OS setting I guess, or default, or whatnot. The -buffering on the 
> sender side only controls when Tcl pushes data into the OS. It doesn't 
> prevent the OS from packaging things as it likes

Yeah, [fconfigure -buffering] is FOR OUTPUT ONLY. (If I said anything 
else, it's a mistake). However, [fconfigure -buffersize] controls the size 
of both the input and output buffers.

An input buffer is always required for using [gets], but is not when using 
[read]. This is because it's extremely inefficient to look for a newline 
when the OS doesn't allow you to «unread» data. I'm talking about 
user-space buffers (the OS does the buffering it wants to have, but you 
don't have direct access to it).

> Hans-Christoph Steiner thommey: that seems doable, better than running 
> [info complete] each time, I suppose <Gotisch> i guess i didnt know what 
> i was talking about again

The thing with the \\ is that it's not sufficient, because you also have 
to count the braces, and braces can be backslashed. (This corresponds to a 
mistake that I made in a previous mail.)

  ______________________________________________________________________
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC