On Thu, 27 Oct 2011, Pavel Strashkin wrote:
> What happened to me is that i had one session (socket fd = 3) which was
> closed by server side so i handled it and closed everything on my side
> (sockets, ...). Net::SSH2 wrapper around the session had not been deleted
> yet so libssh2_session_free had not been called either.
Right, and here's the problem. You handed over the control of the socket to
libssh2, and then you closed it behind its back...
> I think libssh2 should never touch nonblock state or, at least, should set
> it to TRUE and forget about it till the end (i.e. nothing should happen
> inside libssh2_session_free).
The basic principles:
1. the socket is handed over to libssh2 to handle when doing SSH operations
2. libssh2 owns the socket as long as you haven't told it properly that you're
done and want control back
3. when libssh2 stops controlling the socket, it restores the original
blocking state of the socket so that to the application that passed in the
socket in step (1) it won't be any surprise
I don't think just skipping the restoring of the blocking state in step 3 is
going to save you. When you fiddle with the socket before libssh2 has been
told to give it up, you're out on very thin ice. We can't guarantee that
libssh2 won't have to do some other little thing on the socket before it
returns out and you as a user of libssh2 must not assume otherwise.
Or am I wrong?
-- / daniel.haxx.se _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-develReceived on 2011-10-28