On Sun, 2009-03-01 at 12:56 -0500, Martin Peach wrote: > Roman Haefeli wrote: > > On Tue, 2009-02-24 at 21:15 +0000, Martin Peach wrote: > >> Roman Haefeli wrote: > >>> --- Martin Peach <martin.pe...@sympatico.ca> schrieb am Di, 24.2.2009: > >>>> Roman Haefeli wrote: > >>>>>>> On Mon, 2009-02-23 at 21:03 +0000, Martin > >>>> Peach wrote: > >>>> Yes, I agree. I think a status outlet on the [tcpserver] > >>>> could be extended later to have more messages. Some of the > >>>> stuff that gets printed to the Pd window could go there and > >>>> then it could be handled by the patch instead of the > >>>> 'operator'. I don't want to keep adding more > >>>> outlets, so it would output lists with a selector, like > >>>> [comport]. > >>> i totally agree, that instead of adding more outlets it would be better > >>> to > >>> provide additional information on the same outlet with appropriate > >>> selector. > >>> > >> OK it's done for now, in svn. Each time something is sent, you get a > >> "sent" > >> message from the status outlet that gives the number of bytes that were > >> actually sent and the client number. Also a [client( message with no data > >> lists the connections using a "client" selector. > >> The send function doesn't wait any more. If the number of bytes sent is > >> zero, you have to try again. > >> It all needs to be tested... > > > > thank you for implementing those changes. > > > > i finally had a chance (and time) to have a closer look and it turned > > out, that the additional information is actually no gain and this still > > doesn't allow to programm a non-blocking server. > > it seems, that the 'sent' message is output, when something was _added_ > > to the 'send' buffer. actually, we would need this message to appear > > when something was _removed_ from the buffer, which is when a message > > actually was sent. > > > Yes, because the actual buffer is hidden from the user. You should get a > 'sent 0' message when it would block though, I don't know why you don't. > > > > > > with the current implementation, the buffer still overruns without > > having the chance to know this beforehand. whenever i send a message to > > client, i get _immediately_ a 'sent 1 7' message, which i use to > > trigger the next message, etc. so buffer keeps filling and filling. when > > the buffer is full, [tcpserver] blocks pd. so, currently the situation > > is not different from the one before i have started this thread. > > It's not supposed to do that. It should return 'sent 0' when it can't > take any more, never block. Are you sending to the same client or many > different ones? Can you post a test patch that will reproduce the bug? > Something like this should stop when the buffer is full: > > [bang][r stop] > | | > [until] > | > [send 1 7 7 7 7 7 7 7( > | > [tcpserver] > | | | | | > [route sent] > | > [select 0] > | > [s stop] >
ah, now i see your example, i understand how the additional information is supposed to be used. however, i never see a 'sent 0' message. even after pluging the cable back again, so that the buffer is flushed, there is no 'sent 0' message, but only lots of 'sent 1 7' messages. this means, that this example patch didn't work for me. pd was blocked after 5700 or so 8-byte messages. this is with a build from yesterday, so i will check out the todays build as well. you'll hear again from me soon. ;-) roman ___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list