On Fri, 16 Mar 2012, Tom Weber wrote:

But how is that "mode" going to be set? Perhaps in the same manner as blocking, as in:

I was thinking that there mere use of the "atomic read" function would be signal enough. It would then mark the session as done atomic style. I don't think we need to bother with allowing such a mode to get switched off again.

Speaking of blocking/nonblocking, the API confuses me when it comes to nonblocking mode and a complex operation returning EAGAIN. Say that I call libssh2_channel_direct_tcpip_ex() (which involves both a send and receive operation) and it returns EAGAIN, then I wonder:

1) Did EAGAIN happen during send or receive? Do I need to care?

See libssh2_session_block_directions() and you need to care if you want to wait for the correct socket actitity before you try again.

2) Do I have to make the same call again until the operation is complete?

Yes.

3) If yes, do I have to pass in the same arguments?

Yes.

4) If yes, what happens if I pass in other arguments?

It might cause failure.

5) If yes, what happens if I start some other operation before this one is complete?

It might cause confusion and badness.

I think that either the documentation should be clear in this regard (there are no pages about the behavior in general)

Please give us your suggestions!

a clearer asynchronous API should be implemented, and a synchronous one which builds on that.

We've discussed something like that but nobody has yet volunteered to do the work so we keep to the old and existing API...

--

 / daniel.haxx.se
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel

Reply via email to