www.libssh2.org | Daily snapshots | Mailing list archive | Docs | Examples | github

Archive Index This month's Index

Subject: Re: When does read block?

Re: When does read block?

From: Peter Stuge <peter_at_stuge.se>
Date: Thu, 17 May 2012 15:02:22 +0200

Seth Willits wrote:
> I'm now using non-blocking and am trying to figure out when the
> remote side sends an eof.

When libssh2_channel_eof() returns true. Never otherwise.

> I figured eof and read returning 0 would go hand in hand,

That's not correct. As the man page for libssh2_channel_read
documents, 0 bytes returned means no data. It does not mean EOF.

> I would have figured that, like in the above example, if read
> returns 0, it has reached EOF, otherwise it would still be
> returning EAGAIN.

No. The example you showed demonstrated that when a channel is EOF
read will return 0, but you are now suddenly inferring the reverse,
which is simply incorrect.

> I've noticed it does depend on the command I'm running though.

Obviously. Different commands close their output at different times.

> (Looking at the server, cat isn't still running.)

If the channel was used for executing a single program and that
program is no longer running and you have read all data from the
channel (stdout and stderr) then yes libssh2_channel_eof() should
return true, and if not there is a problem somewhere.

> Is this a difference of whether or not the remote program actually
> closes its stdout before exiting or something similar perhaps?

As you probably know a file descriptor (like stdout) always belongs
to a process and thus ceases to exist when the process ends. So the
situation is clearly that the process has not ended yet.

> (Really this more of a curiosity than a necessity to know because
> if I get a 0 I know the remote side is done executing, so it
> effectively is eof.)

Sorry, but that's not correct. Please look at the documentation
and/or play around more with the examples.

libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
Received on 2012-05-17

the libssh2 team