On Thu, 11 Apr 2013, Eric Frias wrote:
Even if we can make simple calls like channel_read/channel_write behave well, there may still be restrictions on some of the higher-level API functions. It seems like we'll end up with two classes of function: things like libssh2_channel_write where and EAGAIN means that nothing was written and there are no restrictions on what your next API call is; and calls like libssh2_scp_send_ex where an EAGAIN might mean that part of the scp_send has executed and it has state saved in the session object.
If we really need to make two classes, then so be it. But I don't think it is that easy to split them up like that. Lots of the functions do multiple operations and EAGAIN just means that one of them couldn't complete and it returned out and it keeps the state for next call.
The funny check in send_existing() that returns the annoying LIBSSH2_ERROR_BAD_USE (which is one of the core issues imho) was added by me just as a way to enforce users to keep calling the function until the send was successful and not trying to push down a new buffer before the previous was completed.
I'm convinved that we can solve that problem in another way that makes things smoother.
In the latter case, the user can still go on to call most other libssh2 functions before continuing the scp_send, but they can't start a call to scp_send with different arguments to start sending a different file because it would screw up the information in the session's scpSend_state.
I agree with Chris that we should most probably strive towards more queueing so that we basically do "high level" atomic packet-operations and then we have a more lower level "data pump" that just keeps sending out the packets in order.
-- / daniel.haxx.se _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
