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-develReceived on 2013-04-11