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 indeed this is a serious efficiency issue) would be for Pd to append a "done" message to each batch up tcl to up-send. On the receiving end you could then just 'string search' to the last occurrence of the special string and send that text safely to the interpreter. cheers M On Sun, Jan 22, 2012 at 11:42:01PM -0500, Hans-Christoph Steiner wrote: > > 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 causes by messages from 'pd' to 'pd-gui' that get split > in the wrong spot. > > I have found one very interesting result: the break always happens at > 48k. At least when I test with the bitmap-madness.pd patch that comes > with tclpd. It is a good test patch because it causes heavy pd --> > pd-gui traffic. So I've tried a bunch of things and not much really > seems to affect it: > > - in configure_socket, change fconfigure -buffering to "line" > - in configure_socket, add -buffersize 500000 to fconfigure > - in s_inter.c set GUI_ALLOCCHUNK anywhere from 1k to 64k > > It seemed that lowering GUI_ALLOCCHUNK did make it happen more often, > but always the break was exactly at 48k. > > Anyone have any ideas? > > .hc > > _______________________________________________ > Pd-dev mailing list > [email protected] > http://lists.puredata.info/listinfo/pd-dev _______________________________________________ Pd-dev mailing list [email protected] http://lists.puredata.info/listinfo/pd-dev
