www.libssh2.org | Daily snapshots | Mailing list archive | Docs | Examples

Archive Index This month's Index

Subject: Re: [libssh2] Non-blocking vs. default mode

Re: [libssh2] Non-blocking vs. default mode

From: Daniel Stenberg <daniel_at_haxx.se>
Date: Sun, 22 Apr 2007 23:28:54 +0200 (CEST)

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_at_lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libssh2-devel
Received on 2007-04-22

the libssh2 team