Hi,
I have a state machine which does the following:
libssh2_channel_open()
libssh2_channel_exec()
libssh2_channel_send_eof()
libssh2_channel_wait_eof()
libssh2_channel_close()
libssh2_channel_read()
libssh2_channel_wait_closed()
libssh2_channel_free()
In the case thet libssh2_channel_wait_closed() returns
LIBSSH2_ERROR_INVAL, the code goes back to the READ state and schedules
more reads until WAIT_CLOSED returns 0. This will cause the
wait_closed() operation to finally return 0 (rather then -34 or -37).
The reason for the enter back into the read state is that
libssh2_channel_wait_closed() checks for eof, and even though the code
has already checked and passed the EOF state, further packets appear to
be sent on the channel. This causes the internal code to mask the EOF
state which can only be corrected by reading packets.
This seems like some kind of odd race condition to me, but fwiw I hope
others find this state machine helpful if implementing nonblocking ssh
connecting software of their own:
https://github.com/pacemaker-cloud/pacemaker-cloud/blob/master/src/trans_ssh.c
Regards
-steve
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
Received on 2012-02-25