pdtk_pd_dio (was Re: [PD] Routing PD audio on MacOSX)

[Krzysztof Czaja]

hi,

looking at the sources (do not use jack right now), I guess it is
the sys_log_error() call in jack callback proc, that is directly
responsible for corrupting things at the pd side.

Looks like the callback kicks in, before the main thread finishes
sending a tcl command (still busy sending coords data for an
array, etc.).  The sys_log_error() itself sends "pdtk_pd_dio 1\n",
which gets stuffed in the middle of a command.

No proof of this being the case, just thought it fits the pattern
people keep complaining about.

Btw, there is another spot, where handling of the stream of gui
messages sent up to the pd-gui is not very robust.  This one is at
the pd-gui side.  In some cases (I get errors with audio on, when
there is a SaveAs dialog open) the tcl notifier invokes the
pd_readsocket() callback from another thread.  Since the pd_tkbuf
buffer is static, it is bound to become corrupt sooner or later.

So, how about making pd_readsocket() thread-safe?

Krzysztof

guenter geiger wrote:
...
>>bad option "creapdtk_pd_dio": must be addtag, bbox, bind, canvasx, canvasy, cget, configure, coords, create, dchars, delete, dtag, find, focus, gettags, icursor, index, insert, itemcget, itemconfigure, lower, move, postscript, raise, scale, scan, select, type, xview, or yview
>>watchdog: signaling pd...
>>watchdog: signaling pd...
>>watchdog: signaling pd...
>>watchdog: signaling pd...
>>
>>This doesn't look like a Jack error... Pd running is 0.37-test3
>>almost official.
> 
> 
> No, but its very strange. Looks like something has gotten pretty messed
> up. Some memory hole probably.