On Sat, 5 Sep 2009, Peter Stuge wrote:
Why can't you just keep track of it and close it when libssh2 is done with
it?
Sorry, I think that's no good. It doesn't make sense to replicate state that
is already neccessary for libssh2 to keep.
State? It's not much of a state, it's a socket the app opened so I don't see
why it wouldn't expect to close it.
libssh2 design isn't perfect, but I think it's important not to tend to
encourage leaking resources.
I cannot see how this encourages anything like that.
Is it really wrong for disconnect to close()? Why? If this was in fact a
successful SSH connection, the socket can not be reused at this point
anyway.
Yes it is wrong, and here's my primary motivations why:
1 - we can't change behavior now without breaking ABI and I will not break ABI
easily, period. The only acceptable way to introduce it now is by adding
something new to the API that makes libssh2 act like this.
2 - I argue that when the app open the socket, the app should expect to also
close it (at the least as default behavior). Another behvior would be
unexpected and a layering problem.
3 - this kind of API (you pass a socket to the library) is also provided by
other libraries and such other libraries usually don't close the socket
either (OpenSSL, GnuTLS, NSS, ...)
4 - I don't see why a socket (in theory) couldn't be re-used for whatever
purpose after a SSH session is successfully finished. It's not libssh2's
job to make that decision.
Can libssh2 automatically detect when the socket could be reused, if ever?
How could it? It's been told to shut down a SSH session and so it does. How
can it make any broader decisions or assumptions on what that
socket/connection can or cannot be used for after the SSH session is
terminated?
--
/ daniel.haxx.se
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
