Subject: Re: [libssh2] libssh2_channel_read_stderr always in blocking mode ?

Re: [libssh2] libssh2_channel_read_stderr always in blocking mode ?

From: Thomas Harding <>
Date: Wed, 1 Aug 2007 18:48:31 +0200

On Wed, Aug 01, 2007 at 05:56:53PM +0200, Thomas Harding wrote:
> >>I (half) solved the problem in non-blocking mode by polling for POLLERR (it
> >>seems to differs from the unix poll, as POLLERR is normally not significant
> >>in pollfd struct) "half", because since an error occurs, calling
> >>libssh2_poll on POLLERR success everytime. In that case, reading for stderr
> >>sipmly returns nothing (it doesn't block).
> >
> >Actually, I find very little use for libssh2_poll() at all... When is that
> >ever useful? Since connections etc already are done outside the library the
> >application already knows the sockets etc and could just as well just use
> >regular poll(). Or what am I missing?
> Maybe a I'm wrong on (libssh2_)poll use: I would to check if data is
> available before to try to read it, because in the case where is nothing
> to read, program waits infinitely for data (and as I said, channel EOF
> never matches in blocking mode after a channel_exec).

I just take a look at my code (it is ether good to let it away a couple
of days before re-read it :)

So, in blocking mode, the regular channel can be check for (in Python
code) None, to break the loop, and this works just fine.

The only problem remaining is that channel.readstderr(BUFFER) waits
infinitely in blocking mode, and
"if channel.poll(10,[SSH2.LIBSSH2_POLLFD_POLLEXT]):"
blocks too (in blocking mode).

Unfortunately, stderr channel is for me a needed feature, for the
purpose I (try to) extend python-ssh2.

Thomas Harding
This email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>
libssh2-devel mailing list
Received on 2007-08-01