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-develReceived on 2009-09-05