Roman Haefeli wrote: > On Sun, 2009-03-01 at 19:30 -0500, Martin Peach wrote: >> I think the blocking happens because the >> connection is gone, not because of the buffer overflowing. > > i am not sure, if understand what you mean here. what i experience: when > i overrun the buffer (by plugging out the ethernet cable to the client), > the pd process of [tcpserver] is completely blocked after having sent > $BUFFERSIZE bytes. it stays blocked, until i plug in the cable back > again. the whole content of the buffer is sent after some seconds and > the server pd instance responds again. this means, that even if the > connection is not completely lost, a blocking of pd could occur.
You can send until the buffer fills up, even if it isn't emptying. I think it blocks because it only checks for at least one empty space in the buffer but then sends more than that. > > if the connection to the client is permanently lost, then there is no > way to make pd responding again, after a buffer overrun occured. > >> If the connection is present the buffer will be emptying as fast as the >> network can drain it, so just pacing the writes should work. Trying to >> write an infinite amount instantly won't. > > i can't follow here as well. it's not about trying to send an infinite > amount of data in zero time. it's about not knowing the current > connection condition, and because of that risking a drop-out. since the > connection condition changes all the time, you cannot implement a > self-adapting system in pd without knowing the internal buffer status > (empty or not). so even if you send data with a fixed rate, it still > could happen, that you trigger the buffer overrun. > > Well I guess empty and almost full are the same as long as we stick to single bytes. So I made [tcpserver] send the messages one byte at a time. This latest version should not block, since it adds only one element to the buffer for each select call that says the buffer is still writeable. Martin _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
