tis 2011-08-16 klockan 04:35 +0000 skrev qus...@gmail.com: > > > And also notify them about EAGAIN returned by write, as I see now it > > will require some tricky changes to their code... > > Does it? From what I could see in the code you quoted earlier they merge > EAGAIN and ret==0 as return 0. But I have no idea of what kind of event > loop handling qxt is using. The upper levels will need to handle that as > EAGAIN somehow. > > Regards > Henrik > > It gets a bit tricky with i.e. ssh tunnels. Let's take -L (TCP_channel <-> SSH_channel). In big simplification:
TCP_channel's readyRead signal is connected to SSH_channel.write(TCP_channel.read()) SSH_channel's readyRead signal is connected to TCP_channel.write(SSH_channel.read()) This works well until SSH_channel writes only part of the read data (meaning that next write will cause EAGAIN). I have to store unwritten data somewhere, wait for EAGAIN to clear and write it to SSH channel. I am not sure how EAGAIN is cleared but it seems that some traffic on "main" SSH channel triggers QxtSshChannelPrivate::d_readyRead: connect(this,SIGNAL(readyRead()),this,SLOT(d_readyRead())); d_readyRead is a function that processes all live ssh channels (so from there I ask to write my remaining unwritten buffer and so on). If there's another SSH channel that has some activity, everything works without a problem, as EAGAIN gets cleared, d_readyRead processes all channels and leftover data gets written. Now the problem arises if I have only one channel on my SSH session: there's no traffic that will trigger QxtSshChannelPrivate::d_readyRead, so I can't send the remaining part of my unwritten data... I am trying different solutions, but each one is uglier than the previous... But I digress... this is not a qxtlib mailing list.
_______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
