Subject: Re: Re: send/recv callbacks (was Re: writing to channel limited to 2 Mb?)

Re: Re: send/recv callbacks (was Re: writing to channel limited to 2 Mb?)

From: Przemys³aw Szczygielski <>
Date: Tue, 16 Aug 2011 10:10:17 +0200

tis 2011-08-16 klockan 04:35 +0000 skrev

> > 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'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