On 4/10/2013 6:44 PM, Chris Hecker wrote:
> This is the recent thread where I had similar issues:
Thanks for the pointer, I don't know how I missed these messages when I
was trying to figure out the problem. It looks like the problem is
pretty well understood, and the problems I'm seeing were described in
one of the messages you linked from Henrik Nordström back in 2011.
> I only thought about/debugged it a bit, but it seemed pretty clear to
> me that the only real fix is an internal queue and changing EAGAIN
> semantics slightly, as discussed in that thread.
That was my first thought too, and it looks like that was the general
consensus. I'm aiming to use libssh2 in production code, so I might
take a crack at it once I get a better handle on the problem.
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. 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.
The use case I'm envisioning is a multi-threaded app that could be doing
file transfers in several threads. A mutex tied to the session will
prevent two threads from accessing libssh2 at the same time, but it
wouldn't do anything to prevent two scp_send calls from interleaving
with each other. It's easy enough to avoid that case, but it's
important to know what I need to avoid to stay safe.
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
Received on 2013-04-11