-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-08-02 22:44, Ivica Ico Bukvic wrote:
This is however not the case whenever you have a high throughput traffic that arrives form various sources at unexpected intervals as the netreceive sends out its message whenever it receives it rather than waiting for the scheduler interrupt which means when that message lands in the middle of another tcl/tk message that is currently being parsed to be sent out to gui (something that commonly is unlikely to take place when the throughput is low but becomes increasingly more likely as the network traffic increases), you end up with garbage output that results in syntax error on the tcl/tk side and thus tcl/tk becomes unresponsive. This is best observed if you monitor pd->tcl/tk activity with debugger on.
hmm, i don't know where you get this idea from, but to me, the code of Pd's networking infrastructure looks, as if a) all incoming traffic was polled for in the main thread b) all output of this traffic (to the Pd-patch) was propery protected by sys_lock()
this basically contradicts your claims of network data being asynchronously fed into Pd's messaging cycle.
of course there might be some bugs in the code, but i rather doubt that.
fgmasdr IOhannes
PS: just for clarity: i'm talking about the [netreceive] object in Pd-vanilla; things might be different in Pd-extended and other networking objects. e.g. iemnet will receive the data asynchronously, but then will pass it to Pd synchronously.