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