On Sun, 22 Apr 2007, James Housley wrote:
>> 1) We have libssh2_channel_set_blocking() and it controls *ALL* functions
>> to do blocking or non-blocking. This didn't work before, and I didn't take
>> this route when I started to add *nb() functions.
>
> You are correct it did not work before, and creating *nb() functions make it
> very easy to slowly migrate to our goal of working fully in both blocking
> and non-blocking mode.
I added the *nb() functions mostly to not change how the old blocking ones
work. Even if the changes would only be subtle. I'm beginning to think I did
the wrong choice.
> In the end I personally think it might be better to only have one, but we
> can all debate that once all the work is done, because right now we need
> both.
I don't agree with the conclusion that we need both.
> Right now an existing program works with libssh2 and uses the non- blocking
> functions, lets only talk about libssh2_sftp_read(). After calling
> libssh2_sftp_read() libssh will be told it is in non-blocking mode, because
> at startup the library wasn't set to blocking (because the function didn't
> exist before).
No, that doesn't sound right. The application doesn't use any non-blocking
functions and thus all operations it does and asks for are performed blocking.
> Later on the program calls libssh2_channel_close() or similar, but now
> instead returning -1 on failure and 0 on success -2 (*_EAGAIN) will be
> returned.
No. Only *nb() functions will return *_EAGAIN as they are the only
non-blocking ones.
> This is bacause the "non-blocking" sftp functions set the libssh2 library
> into non-blocking mode, when it shouldn't be.
The non-blocking functions set the (internal) mode to non-blocking, call the
underlying function and set the mode back to what it was previously. So an
application can use blocking and non-blocking function in a mixed fashion,
should anyone think that is a good idea.
And if there is any current confusion, we should just make sure that the
internal state is by default set to blocking.
> Basically functionality has been changed in a subtle way that will cause
> programs to break.
If there are (subtle) changes done to the blocking functions of the 0.14 API,
then I think we should try to fix them where we think it makes sense. I don't
think our design necessarily have to imply almost any changed behavior.
> I am saying the library has to know for sure if it is in blocking or
> non-blocking mode.
It does! Every function that isn't called *nb is blocking. The *nb ones are
non-blocking.
> This can be done with the added libssh2_channel_set_blocking() function, but
> this won't help existing programs.
1) libssh2_channel_set_blocking() is not added. It was present in the 0.14 API
as well.
2) If libssh2_channel_set_blocking() was used in an old existing application,
then wow, they used a function with basically no effect to what libssh2
did and if we now give it some functionality then the applications will
behave differently - of course possibly better!
Due to the old broken functionality and due to this new way of offering (true)
non-blocking operations, I suggest we remove the
libssh2_channel_set_blocking() function completely. I don't think it serves
any useful purpose.
And I don't believe in bending over backwards just to stay semi-compatible
with the former API. I think it is better to fix these problems once and for
all now. We're changing the ABI anyway and small tiny changes in people's
libssh2-using source code should be acceptable. IMHO.
> Or, the new function I proposed can be added so libssh2 just figures it out
> for itself.
I don't see in what situations libssh2 wouldn't know which mode to use/set.
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
libssh2-devel mailing list
libssh2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libssh2-devel
