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
