tis 2011-08-16 klockan 04:35 +0000 skrev qus123_at_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.
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's readyRead signal is connected to
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:
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.
Received on 2011-08-16