On Wed, 21 Jan 2004, Krzysztof Czaja wrote:
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.
oops, of course ... thanks for your analysis. This is for sure the problem. (At least one of them).
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?
I think I will solve the jack problem with a lockfree solution. Its already bad enough that a DIO error occurs.
I assume that the pd_readsocket problem is Unix specific, as on Windows the socket gets polled ?
Guenter
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.