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-develReceived on 2012-03-16